how to tell with perforce if you are logged in with -a or just a host login? - perforce

I'd like a method to detect if the current login is limited to a host, or is valid across all hosts. This is needed for error detection when using things like LSF.
I'm aware of p4 login -s, but I haven't figured out how to tell the difference between -a and per host

If you have the user's password (or are a superuser) you can run login again with different flags to see what the ticket values are with different host limits -- running login when you already have a valid ticket does not generate a new ticket, it just returns the existing (server-side) ticket with the appropriate hashing. (p4 logout -a invalidates the server-side ticket.)
So for example, if I have this ticket and want to figure out whether it's host-bound:
C:\Perforce\test>p4 tickets
localhost:unknown (Samwise) 18D5A046F46601FD67827A39D6449A7E
as a superuser I can do:
C:\Perforce\test>p4 login -h 1.2.3.4 -p Samwise
22B95BDC5DE0571C2BF92A1E688C97E3
C:\Perforce\test>p4 login -h 127.0.0.1 -p Samwise
2ECEA5DDFFEB53E4DAFA29F70DD321A4
C:\Perforce\test>p4 login -a -p Samwise
18D5A046F46601FD67827A39D6449A7E
Note that the ticket I got with login -a matches the one in my ticket file, so I know that my current ticket is a global ticket. (The ticket values I got from login -h are the same ticket value hashed with the provided host.)
If I'm not a superuser, I can't use the p4 login USERNAME shortcut and will have to re-enter my password for each login command.

Related

How to configure yocto so that no one should be able to login as root in yocto image

I am building a yocto image and I do not want anyone being able to login as root in it. I do not wish to remove the account but here is what I want to accomplish.
I want to disable root account access from terminal as well as ssh or create a password that will never validate.
I want to make all files root owner and set them to 700 permissions.
Add these lines to your image recipe.
inherit extrausers
EXTRA_USERS_PARAMS = "usermod -L -e 1 root; "
This locks the password and expires the account. Make sure you don't have debug-tweaks or empty-root-password in your IMAGE_FEATURES.
$ man usermod
...
-e, --expiredate EXPIRE_DATE
The date on which the user account will be disabled. The date is
specified in the format YYYY-MM-DD.
An empty EXPIRE_DATE argument will disable the expiration of the
account.
This option requires a /etc/shadow file. A /etc/shadow entry will
be created if there were none.
...
-L, --lock
Lock a user's password. This puts a '!' in front of the encrypted
password, effectively disabling the password. You can't use this
option with -p or -U.
Note: if you wish to lock the account (not only access with a
password), you should also set the EXPIRE_DATE to 1.
Checked:
Login with ssh is not possible, even though PermitRootLogin yes is set in /etc/ssh/sshd_config
$ su - root is not possible, even though the login shell in /etc/passwd still points to /bin/bash instead of /sbin/nologin
Login to ftp server via root is not possible
Not Checked:
I did not check what happens if we add systemd.unit=rescue.target or systemd.unit=emergency.target to the kernel commandline.
... ?

Perforce log in as someone else

In the doc's I'm reading: To log in to Perforce automatically, you can save your password in a text file, and redirect p4 login to read from that file. For example, if you saved your password to a file called password.txt, the command would be:
Command:
p4 login < password.txt
However I've created a new local account using the following commands:
p4 user -f test
p4 passwd perforce-bot
When I now wan't to login with p4 login test < password.txt it complains about "Perforce password (P4PASSWD) invalid or unset".
How should I understand that? This operation works fine if I first do a p4 login (I'm an admin) and then run that snippet, it basically feels like sudo'ing as someone else, but I would want to use it without the need to login as my user first so I can run it as a cronjob on any machine.
These are two different commands:
p4 login: authenticates the current user ($P4USER) by prompting for a password
p4 login USER: authenticates an arbitrary other user IF already authenticated as a super user
Note also that if you run p4 passwd perforce-bot, you're setting the password for a user called perforce-bot (again, this is an admin command).
To temporarily switch the current user without resetting $P4USER, use the -u global flag:
p4 -u test user # creates a new user called "test"
p4 -u test passwd # sets the password for "test"
p4 -u test login # login "test" via stdin password prompt
p4 -u test <any command> # run any other command as "test"

Perforce: run script as particular user and workspace

I have a powershell script that does various things, including running p4 commands such as syncing, creating a changelist and checking files into it, create a label etc. My script works fine when I run it on my development environment as my user.
Now I would like to run the script on another machine, against a specific workspace, and a specific Perforce user. Is there some set of commands I can add to the beginning of my script so that I can set the perforce user and use a specific workspace for the remainder of the script? If yes, I'd like to know 2 ways of doing this, one with the password in plain text (for testing and verifying), and one without it (for production use).
Releated: I think part of my problem is that I don't fully understand how the session user is determined. On the other machine, if I try to run any p4 command, I get the message: "Perforce password (P4PASSWD) is invalid or unset." I got that message even if I try:
p4 login abc
"abc" can be anything and I get the same message. I must be wrong in thinking that the "login" command can be used to login as a particular user. I was expecting it to prompt me for abc's password, rather than telling me I need to set a password before I can login as someone else.
But if I type in this:
p4 login
I am prompted to enter in a password. But for what user would that be? My Windows account user? What if I don't have a perforce user with the same name as my windows account user?
This is the doc page you need:
http://www.perforce.com/perforce/doc.current/manuals/cmdref/envars.html
In general, this should do the trick (with the current version of the command line client that supports "p4 set" on all platforms):
p4 set P4USER=username
p4 set P4CLIENT=clientname
p4 login
The "p4 login USERNAME" syntax is used when you've already logged in as a super user to get a login ticket for a different user (with no password prompt). Like all other commands, "p4 login" uses your P4USER to determine who you're running the command as.
To Auto login via powershell, login -a means allow login from any ip...
$USER = "My.User"
$PASS = "P455w0rd"
Out-File -FilePath C:\p4pass.txt -InputObject $PASS -Encoding ASCII -Width 50
cmd /c "p4 -u $USER login -a < `"C:\p4pass.txt`" " 2>&1
To specify the user, workspace and server:port append the below before the perforce command... e.g:
p4 -u ${USER} -c ${WORKSPACE} -p ${perforce:1666} login -a
p4 -u ${USER} -c ${WORKSPACE} -p ${perforce:1666} sync -f -q //...#head
To specify a ticket, get the ticket from the command:
p4 tickets
and specify it with an upper case -P, e.g:
p4 -u username -P 5E8ED75FB5086BE82D9BCD5561D32AEE sync...

Why must a UNIX user have a password?

I am configuring the ssh server on my raspberry pi so that it only supports key-based authentication.
I have created a user on the server and set up the ~/.ssh directory with my public key and correct permissions.
The user is currently marked as 'locked' because it does not have a password. This causes openssh to refuse the connection.
# /var/log/auth.log
Aug 9 09:05:26 raspberrypi sshd[6875]: User foo not allowed because account is locked
Aug 9 09:05:26 raspberrypi sshd[6875]: input_userauth_request: invalid user foo [preauth]
Aug 9 09:05:26 raspberrypi sshd[6875]: Connection closed by 192.168.0.4 [preauth]
Ideally, I don't want a password. I have already authenticated via PKI.
Perhaps I could set the password to 'password', or a random string - but that seems messy.
Any recommendations?
EDIT:
Just to clarify, my account is locked because it doesn't have a password, i.e.
$ passwd -u foo
passwd: unlocking the password would result in a passwordless account.
You should set a password with usermod -p to unlock the password of this account.
Petesh solution is correct:
usermod -p '*' foo
From the man page for shadow:
"If the password field contains some string that is not a valid result of crypt(3), for instance ! or *, the user will not be able to use a unix password to log in (but the user may log in the system by other means)."
No, it's telling you the account is locked, not that it doesn't have a password. You lock and account to prevent people from logging in using that account; even via SSH. You generally can only switch to a locked account using su or sudo.
The rules are described in the shadow manual page which says:
If the password field contains some string that is not a valid result of crypt(3), for instance ! or *, the user will not be able to use a unix password to log in (but the user may log in the system by other means).
The logic is * will never match a password, but doesn't mean locked, while ! means locked.
This encrypted password is stored, generally, in the shadow file and can be changed using the passwd command or the usermod command. If you wish to change the password to one that doesn't work, then you can change to one starting with *, which will never match a password, so, for example, using the usermod command:
bubble ~ [2]> sudo usermod -L freerad
bubble ~> sudo grep freerad /etc/shadow
freerad:!*:16197:0:99999:7:::
This is a locked freerad account. ssh should prevent you from logging in using that account even if you use public/private key pairs.
bubble ~> sudo usermod -p '*' freerad
bubble ~> sudo grep freerad /etc/shadow
freerad:*:16291:0:99999:7:::
This freerad account has a never-matchable password. The account is not locked, but if you were to login using ssh public/private keys it would not prevent you from logging in.
Try unlocking it with
passwd -u foo
Being locked and not having a password are two different things.

openam - create a user with ssoadm

I have new goal. Be able to create users of openam with ssoadm.
I have read the documentation of Openam
https://wikis.forgerock.org/confluence/display/openam/ssoadm-identity#ssoadm-identity-create-identity
However, I don't know how to create a user and then assign it a password. For now I just can create users by openam web, but is not desirable, I want to automatize.
Somebody know how can I create a normal user with ssoadm?
./ssoadm create-identity ?
./ssoadm create-agent ?
UPDATE: I have continued with my investigation :) I think I'm closer than before
$ ./ssoadm create-identity -u amadmin -f /tmp/pwd.txt -e / -i Test -t User
Minimum password length is 8.
But where is the parameter for password?
Thanks!
To create a new user in the configured data stores you could execute the following ssoadm command:
$ openam/bin/ssoadm create-identity -e / -i helloworld -t User -u amadmin -f .pass -a givenName=Hello sn=World userPassword=changeit
Here you can see that I've defined the password as the userPassword attribute, which is data store dependent really. For my local OpenDJ this is perfectly legal, but if you are using a database or something else, then you'll have to adjust the command accordingly.
If you don't want to provide the attributes on the command line, then you could put all the values into a properties file, for example:
$ echo "givenName=Hello
sn=World
userPassword=changeit" > hello.txt
$ openam/bin/ssoadm create-identity -e / -i helloworld -t User -u amadmin -f .pass -D hello.txt
But I must say that using OpenAM for identity management is not recommended, you should use your data store's own tools to manage identities (i.e. use an LDAP client within your app, or just simply use the ldap* CLI tools). You may find that OpenAM doesn't handle all the different identity management related tasks as normally people would expect, so to prevent surprises use something else for identity management.

Resources