After the first release of hardening for SSH I sometimes ran into the issue, where I suddenly couldn’t log into an account anymore. Since hardening prohibits the use of passwords, the culprit isn’t found immediately. The client’s SSH key was authorized and there wasn’t an obvious reason why he shouldn’t be able to login.
A quick solutions that comes to mind after throwing this question at Google, is to set
It works as advertised. But why?
If you look at
man sshd_config it will tell you, that:
UsePAM Enables the Pluggable Authentication Module interface. If set to ``yes'' this will enable PAM authentication using ChallengeResponseAuthentication and PasswordAuthentication in addition to PAM account and session module processing for all authentication types.
Both of these authentication types are disabled by hardening, so
UsePAM should remain off by default.
However, if you enable this setting, there is another implication that follows: By default the system will not allow entry to any “locked” user. Once
UsePAM is enabled, even locked users can enter.
Initially this looks wrong. A locked user should not be “able to get into the system”, right?
Not quite so. In
passwd terms, user locking results in:
Lock a user's password. This puts a '!' in front of the encrypted password, effectively disabling the password.
In essence, it’s about disabling password-based login. So in your
/etc/shadow, you will see (for user
! in the password hash is something that cannot be reached with any password input, since the user’s input is always hashed. In terms of
passwd, account locking is not about disabling the account, as the man-page shows further down:
Note: if you wish to lock the account (not only access with a password), you should also set the EXPIRE_DATE to 1.
This definition of locked accounts doesn’t make much sense in the context of SSH with key-based logins. The obvious solution of
UsePAM set to
yes has the nice byproduct of interpreting “locked accounts” as “doesn’t have a password” (which can be ignored for key-based logins) instead of “isn’t allowed to log in”.
For those that want to remain compliant without involving PAM in SSH, there’s still a way to get users with impossible password-login without locking the account. Essentially, replace the
! in the password hash with any equivalent like
In normal login terms, this account is not locked, while making any password input fail. SSH in the default hardening configuration will allow users with keys to get in. This way may be longer, but it keeps a few settings at their intended purpose without aiming for a simple byproduct. Though if you prefer PAM, you still have the option of enabling it.
If you have
adduser installed, you gain control over this behavior when creating new users. This example demonstrates the difference:
> adduser --disabled-password kano > grep kano /etc/shadow kano:*:16280:7:60:7:::
> adduser --disabled-login kano > grep kano /etc/shadow kano:!:16280:7:60:7:::
The former can log in without activating PAM in SSH, the latter can’t.
A way to manage existing users is to use
passwd. However, unlocking accounts that only have an
! in their hash field will result in an error:
> usermod -U kano usermod: unlocking the user's password would result in a passwordless account.
This is annoying, but unfortunately correct: When locking an account, an
! is added in front of the password hash. Running unlock simply attempts to remove the
! and use the “old” password. Without a previous password, that doesn’t work.
The alternative is to set an impossible password for the user:
> usermod -p "*" kano > grep kano /etc/shadow kano:*:16280:7:60:7:::
This will keep the user unlocked, while prohibiting password-based logins with