Jump to content


login fails using P4PASSWD env variable


  • Please log in to reply
7 replies to this topic

#1 adams_s

adams_s

    Member

  • Members
  • PipPip
  • 10 posts

Posted 02 January 2020 - 09:26 AM

I am unable to get Perforce login to work with password set as an env variable.

I'm able to login normally from the command line using "P4 login" - I get prompted for a password, and this is accepted by our server.

Based on the the instructions listed in https://community.pe.../s/article/3413 ...
- I've generated the capitalzied MD5 hash of my password.
- echo %P4PASSWD% returns the hash, so this is properly set
- echo %P4USER% returns my user name, so this is also properly set

"p4 login - s" returns "Perforce password (P4PASSWD) invalid or unset."

Am I missing something?

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1038 posts

Posted 07 January 2020 - 03:49 PM

Authenticating via P4PASSWD is less secure than using a login ticket, so your server's security setting might not allow it.  What's the "security" counter set to?

#3 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 218 posts
  • LocationSan Francisco, CA

Posted 09 January 2020 - 11:30 AM

Also worth noting that if you are using LDAP authentication, 'security = 3' is the default/required, but I'm not sure it actually sets it.
-Matt Janulewicz
Currently unemployed, looking for work in Boise, ID!

#4 adams_s

adams_s

    Member

  • Members
  • PipPip
  • 10 posts

Posted 11 February 2020 - 11:03 AM

View PostMatt Janulewicz, on 09 January 2020 - 11:30 AM, said:

Also worth noting that if you are using LDAP authentication, 'security = 3' is the default/required, but I'm not sure it actually sets it.

Yes, it turned out to be this after all, discovered it by chance while digging through the LDAP integration documentation. I'm working around the problem by storing an unencrypted password as an env var, retrieving it manually and explicitly logging in from script with

  
echo MYPASSWORD | p4 login

Ironically, it's made my overall system less secure, but such is life :)

#5 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 183 posts

Posted 11 February 2020 - 06:36 PM

Why not set a long Timeout in a group and just let the ticket mechanism do the work?

#6 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 218 posts
  • LocationSan Francisco, CA

Posted 16 February 2020 - 11:15 PM

View Postadams_s, on 11 February 2020 - 11:03 AM, said:

Yes, it turned out to be this after all, discovered it by chance while digging through the LDAP integration documentation. I'm working around the problem by storing an unencrypted password as an env var, retrieving it manually and explicitly logging in from script with

  
echo MYPASSWORD | p4 login

Ironically, it's made my overall system less secure, but such is life :)

Yeah, it's sometimes a pain when you have robots doing stuff. For what it's worth, the SDP puts the admin password in a plain text file then redirects it to 'p4 login'. Kind of the same thing.
-Matt Janulewicz
Currently unemployed, looking for work in Boise, ID!

#7 adams_s

adams_s

    Member

  • Members
  • PipPip
  • 10 posts

Posted 13 March 2020 - 10:31 AM

View PostMiles O, on 11 February 2020 - 06:36 PM, said:

Why not set a long Timeout in a group and just let the ticket mechanism do the work?

That's certainly possible, I just prefer having my scripts manage their own authentication. Also, a login session that is created by human-at-keyboard and then times out at some unspecified time isn't my thing. It's purely style/opinion though.

#8 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1038 posts

Posted 13 March 2020 - 02:59 PM

View Postadams_s, on 13 March 2020 - 10:31 AM, said:

That's certainly possible, I just prefer having my scripts manage their own authentication. Also, a login session that is created by human-at-keyboard and then times out at some unspecified time isn't my thing. It's purely style/opinion though.

You can create an "unlimited" ticket that will never time out, but that still is only usable from a single host -- so if someone steals it from your environment, their ability to cause mischief elsewhere is limited, unlike if they steal the plaintext password by glancing at your script.  In addition, if you ever feel paranoid about your ticket's security, you can manually reset the ticket (without resetting your password or modifying the script) by doing "p4 logout -a; p4 login".

Using login tickets also lets you separate the authentication credentials (which can just live in the tickets file) from the script.  That way you can check the script into Perforce and let other people see it without exposing your password to them.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users