Completely lock user account on server, including ssh

Question

I need to lock some user accounts, without messing with their HOME, if at all possible.

Normal way would be usermod -L user but it seems to leave open ssh login with public key authentication (routinely used on this server).

I know I could just mv /home/user/.ssh /home/user/_ssh or something similar, but is that the right way of doing this?

What am I missing?

Answer 1

The documentation, man usermod, gives you the recommended solution:

-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.

And then

-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.

So, turning this into a real example

usermod -L -e 1 someuser     # Lock
usermod -L -e '' someuser    # Unlock

If you might have a default expiry date set up in /etc/default/useradd you can include its value - if any - as part of the unlocking process:

usermod -U -e "$( . /etc/default/useradd; echo "$EXPIRE")" someuser

Jobs scheduled through cron are also disabled for a user with an expired account but not for just a locked account. Error messages from journalctl -u cron show the expired user's account name (in this instance test2):

Apr 30 11:47:01 pi CRON[26872]: pam_unix(cron:account): account test2 has expired (account expired)
Apr 30 11:47:01 pi cron[472]: Authentication failure
Apr 30 11:47:01 pi CRON[26872]: Authentication failure

Jobs scheduled with at remain unattempted. (It's not clear to me if they will ever be run once they are past their due date; empirically it seems not.)

Other processes already running under the locked and expired account remain unaffected and continue to run.

Answer 2

After issuing "usermod -L user" you can deny ssh access by adding this line to the end of the /etc/ssh/sshd_config file:

DenyUsers user

Or you could create a group for this purpose so you can deny ssh login by adding users to the group:

groupadd deny-ssh
usermod -a -G deny-ssh user

And add the group to the end of the /etc/ssh/sshd_config file:

DenyGroups deny-ssh

After every change to the /etc/ssh/sshd_config file make sure to reload the sshd daemon in order to apply the changes:

systemctl reload sshd

The reload command will load the new settings and keep any existing ssh sessions open.

---

Alternatively, you could change the users shell so even if he logins he won't get a shell:

usermod --shell /usr/sbin/nologin user

I could recommend to create a simple bash script that will do all of the above with just one command.

deny-logon.sh:

#!/bin/bash

#Lock user account
usermod -L $1

#Deny SSH connections
usermod -a -G deny-ssh $1

#Remove user Shell
usermod --shell /usr/sbin/nologin $1

#Reload sshd
systemctl reload sshd

Now you simply have to execute the script like that:

./deny-logon.sh user

And it will automatically make all the above changes for the "user".

EDIT: @roaima solution is the most correct one, expiring an account disables every access to it and should be done if you want to stop a user from loging in.

Answer 3

Your should be able to disable ssh-logins for users by adding their usernames or groups in

/etc/ssh/sshd_config

under the setting DenyUsers and/or DenyGroup.

See man 5 sshd_config.

Don't forget to HUP the sshd.

Answer 4

To properly prevent access for a user on an SSH server, the correct solution is to modify the SSHD config so that they are explicitly denied access using the DenyUsers and/or DenyGroups settings. I would normally suggest using DenyGroups and creating a dedicated group for this purpose that you add anyone who is not supposed to have SSH access to.

To fully lock the account you also need to lock their password, set it expired (both using either usermod), and change their login shell to /sbin/nologin so that other login mechanisms do not let them in. You may need to do even more than that in some cases as well (for example, if the server runs Samba and the user had access to file shares through SMB, you probably need to lock their Samba account as well using smbpasswd).

---

Why is just locking the account with usermod not sufficient?

This comes down to the fact that an account is ‘locked’ in the traditional UNIX sense by making it such that no matter what password the user tries to use, it will never match what is in the password database. This means, rather importantly, that locking the account with usermod only affects those services which are authenticating against the system password database (on a modern Linux system this would mean those services which are configured to use the pam_unix PAM module for authentication).

However, SSHD only actually authenticates against the system password database if the password or challenge-response authentication mechanism is being used. Public key authentication, as well as any other authentication mechanisms (such as GSSAPI or s/key) only involve the system password database to check that the account exists, so they will generally work just fine with a locked account.

Why is setting the login shell to /sbin/nologin not sufficient?

This has to do with the fact that there are a number of ways to access a system as a specific user account that have nothing to do with a login shell.

The most relevant one here is that SFTP, SCP, and SSH with an explicitly specified command do not invoke a login shell at all. That means that even with the login shell set to /sbin/nologin, you can usually get a working shell on a system as a user by running ssh -t user@host /bin/sh (the -t is needed to explicitly request pseudoterminal allocation, which is in turn required to get some things, such as sudo or vim to work correctly from the resulting shell), and you can almost always still use SFTP and SCP to move files around.

Another example of this would be using sudo -u user /bin/sh to get a working shell as a given user from an existing session on the system as a different user. That will work even if the target user’s login shell is set to /sbin/nologin, though if the account is also locked using usermod you will have to run it as the root user (at least, in any standard sudo configuration).

Answer 5

Locking the account is the correct way. You may also want to remove the authorised_keys file to defeat SSH.

Remember there are other ways besides SSH to logon.

Doing anything with "*rc" routines is clumsy, but commonly used for "sftp only" accounts if it is a utility account foe sftp or SCP say.

But !password is better that changing their password if restoration is required.

As always, keep backups, and securely.

Answer 6

If you don't want to rely on assumptions about how different software will treat locked or expired state in the shadow file, a big hammer to completely lock out as user account is to remove its line from the passwd file (keeping a backup somewhere else). With this change, there is no longer any mapping from the user name to the uid or home directory, so nothing (sshd or otherwise) can look up the username, find the homedir and authorized_keys file (or similar) and act on it.