One of our user is on leave for few days
and I want to stop him accessing the systems for these days ..
should I
Add * to his encrypted password
or delete the user from etc /password file
or Remove the user encrypted password
or rename username to root
or set his userID to -1
Which option should i go for out of the above
It's for an access to a Linux system (Ubuntu). Not sure where you found those listed options, but in general try to use the system's tools to manage the system.
Simply lock the account:
sudo passwd -l [user_name]
Alternatively you can put an expire date on the account:
sudo passwd -e YYYY-MM-DD [user_name]
To unlock a locked account:
sudo passwd -u [username]
Related
How can I check if the current user has all privileges to use useradd and groupadd for creation of users and groups?
I don't want to request root privileges (e.g. requireing to be root or calling sudo) for my bash script unnecessarily. Instead I just want to ensure that the privileges are there to just use those commands.
The commands:
$ ls -l $(which useradd) $(which groupadd)
-rwxr-xr-x 1 root root 93136 Mai 28 2020 /usr/sbin/groupadd
-rwxr-xr-x 1 root root 147160 Mai 28 2020 /usr/sbin/useradd
As useradd and groupadd commands need some extra priviledges to run, you can setup access to sudo for specific commands like useradd and groupadd like below :-
Please go through it once, it will make most of the things clear to you
Controlling Access To sudo
The /etc/sudoers file configures the programs that users can access using sudo, along with whether or not a password will be needed.
The system administrator adds users to this file using the /usr/sbin/visudo command. Each non-comment line in the file has two parts:
A username ("<USER_NAME>"), or a group name ("%<GROUP_NAME>").
A list of machine names where a program may be run, or the keyword ALL. Following an equal sign (=), a list of user identities the command may be run as, enclosed in round brackets (parenthesis); the wildcard ALL may also appear. Finally, a list of applications that may be run as the named users; the keyword ALL is a wildcard.
The following examples should help make this clear:
<USER_NAME> ALL=(ALL) ALL
# User <USER_NAME> can execute any command as any user, but must know the password to the <USER_NAME> account.
<USER_NAME> ALL=(root) shutdown
# User <USER_NAME> can execute only command shutdown, but must know the password to the <USER_NAME> account.
<USER_NAME> ALL=(root) NOPASSWD: /usr/bin/id
# User <USER_NAME> can execute only the application /usr/bin/id; no password will be needed.
<USER_NAME> ALL=() NOPASSWD: /usr/bin/id
# User <USER_NAME> can execute only the application /usr/bin/id; no password will be needed.
Once the system administrator has entered the necessary setup into the /etc/sudoers file, users can safely access privileged system resources and activities like this:
$ sudo useradd username
No awkward quoting on the command line, just prefix the command you want with the word sudo. If you want to run the command as a user other than root, just add the -u username switch:
$ sudo -u <USER_NAME> useradd username
There will be a log entry written to the /var/log/secure file to show who did the deed.
Of course, the sysadmin can configure sudo not to request a password. In this case, the command is immediately executed although the audit trail entry will still be written.
Reference :- Sudo Tutorial
Please reach in the comments section for any help
Will be glad to help !!!
Assuming that you need root or sudo to add new users (same for group), you can check if the user has sudo rights, by checking if he is in the corresponding groups.
getent group sudo // shows all users in groupd sudo
Dont know what system/distro you are on - but on arch for example sudoers are in group wheel...
On Linux debian-linux 5.10.0-6-amd64 #1 SMP Debian 5.10.28-1 (2021-04-09) x86_64 GNU/Linux,
you can try this way in your script.
groupadd 2>/dev/null ; if test $? -eq 2 ; then echo ok ; else echo bad ; fi
If you can access groupadd or useradd, the return value is 2 because there is missings arguments.
If you can't acess groupadd or useradd, the return value is 127.
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.
... ?
For example I have one user named user1 on my linux server, with password p1. Then I set up a ldap server and add user1 with password p2. Turns out now I can login as user1 with both p1 and p2. How can I disable p1?
passwd -l user
That will lock the user account as you are using LDAP authentication you not need user on server. And passwd -u user will undo this
Alternatively, you can accomplish the same thing by prepending a ! to the user's password in /etc/shadow (this is all passwd -l does behind the scenes).
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.
My understand is that sudo is executes a given command with root privileges, but I experienced that entering a command in Terminal with sudo caches the authorization. How does it actually works?
For e.g.
sudo fdisk -l
[sudo] password for xxxxx:
(once I authorize by entering a password, successive sudo commands are not prompting for passwords)
sudo fdisk -l
(not prompting for password)
sudo mount -t vfat /dev/sda1 /media/test
Whether sudo is really a wrapper for su (substitute/switch user)?
man sudo would tell:
Security policies may support credential caching to allow the user to
run sudo again for a period of time without requiring authentication.
The sudoers policy caches credentials for 15 minutes, unless overridden
in sudoers(5). By running sudo with the -v option, a user can update
the cached credentials without running a command.
It also says:
-k [command]
When used alone, the -k (kill) option to sudo invalidates
the user's cached credentials. The next time sudo is run a
password will be required. This option does not require a
password and was added to allow a user to revoke sudo
permissions from a .logout file. Not all security policies
support credential caching.
When used in conjunction with a command or an option that
may require a password, the -k option will cause sudo to
ignore the user's cached credentials. As a result, sudo
will prompt for a password (if one is required by the
security policy) and will not update the user's cached
credentials.
Here goes proper detail for you:
Yes sudo and su command is bit different:
1.) When we fire su command it will act as a pure Admin (We can same permanently for that session time)
2.) Whereas, sudo command is acts as a having or assigning admin priviledges (We can say temporary for that session only)
Another Example:
In windows system, hope you have checked right click properties like "Run as Administrator", this is same as sudo.
And if we login or switching user to Admin, it purely acts as a Administrator for all the programs.
Hope you have understood my example, this was best from my side
In your /etc/sudoers you can edit the sudo configuration.
There is a default timeout of authorization.
You can even assign some of your user using sudo without requirement of a password.
Or some user once authorized, it won't require password until you logout your system.