How to unlock account for public key ssh authorization, but not for password authorization?

Question

The ssh won't let me login, because account is locked. I want to unlock the user on my server for public key authorization over ssh, but do not enable password-ed login.

I've tried:

# passwd -u username
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.

Auth log entries:

Mar 28 00:00:00 vm11111 sshd[11111]: User username not allowed because account is locked
Mar 28 00:00:00 vm11111 sshd[11111]: input_userauth_request: invalid user username [preauth]

Answer 1

Whatever you do, don't leave the account in the state left by passwd -u, with a blank password field: that allows logins without entering a password (except over SSH, because SSH refuses that).

Change the account to have no password, but be unlocked. An account has no password if the password hash in the password database is not the hash of any string. Traditionally, a one-character string such as * or ! is used for that.

Locked accounts also use a special marker in the password field that cause the string not to be the hash of any string. The marker is system-dependent. On Linux, the passwd command marks locked passwords by putting a ! at the beginning, and OpenSSH treats the account as locked if the field begins with !. Other Unix variants tend to use similar but not identical mechanisms, so take care if your password database is shared among a heterogeneous network.

On Linux, you can disable password-based access to an account while allowing SSH access (with some other authentication method, typically a key pair) with

usermod -p '*' username

The user won't be able to change the account back to having a password, because that requires them to enter a valid password.

If you want, you can instead configure SSH to refuse password authentication, regardless of whether the account has a password. You'll still need to arrange for SSH not to consider the account to be locked, so for example on Linux you'll need to remove the ! from the password field (but don't make the field empty — set it to * as explained above). To disable password authentication for SSH, add a PasswordAuthentication directive to /etc/sshd_config or /etc/ssh/sshd_config (whichever it is on your system). Use a Match block to make that directive only apply to a specific user; Match blocks must appear

…
Match User username
    PasswordAuthentication no

Answer 2

Unlock the account and give the user a complex password as @Skaperen suggests.

Edit /etc/ssh/sshd_config and ensure you have:

PasswordAuthentication no

Check that the line isn't commented (# at the start) and save the file. Finally, restart the sshd service.

Before you do this, ensure that your public key authentication is working first.

If you need to do this for only one (or a small number) of users, leave PasswordAuthentication enabled and instead use Match User:

Match User miro, alice, bob
    PasswordAuthentication no

Place at the bottom of the file as it is valid until the next Match command or EOF.

You can also use Match Group <group name> or a negation Match User !bloggs

As you mention in the comments, you can also reverse it so that Password Authentication is disabled in the main part of the config and use Match statements to enable it for a few users:

PasswordAuthentication no
.
.
.
Match <lame user>
    PasswordAuthentication yes

Answer 3

You don't need to enable or set passwords, and you really shouldn't, if you're already using strong keys. Just re-lock your account (sudo passwd -l username) from an existing session and fix your SSH configuration.

The reason why this happened is probably because you have edited one of the default SSH daemon settings (in /etc/ssh/sshd_config).

Change this in /etc/ssh/sshd_config and restart SSH:

UsePAM yes

Enabling PAM within SSH will allow you to still log in, even with a password removed. Whatever you do, don't set an empty password or similar; locking the password field doesn't have to mean locking your entire account out.

Quick tip when configuring the SSH daemon: keep another session open (in another window) whenever making changes to your SSH configuration, and then test that you can still log in; if you inadvertently break your access, use your earlier session to fix it.

(Disclaimer: I work at Userify.)

Answer 4

I had this problem on CentOS 7. I am a regular Debian-based Linux user so I was a fish out of the water. I noticed that in some of the servers it worked and in just one it didn't. The audit.log said nothing useful and the secure.log did not give anything either. I found that the only real difference was some security context differences on files and directories between those that worked and those that didn't. Get the security with

sudo ls -laZ <user-home>/.ssh

of the directory (I'm assuming a lot of defaults on sshd_config).

You should see some ssh_home_t and user_home_t attributes. If you don't, use the chcon command to add the missing attributes.

For example

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

In my case, my suspicion is that the user was created in a non standard way. His home was a directory in /var/lib.

More info in: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/

Answer 5

I hit this issue on Alpine Linux, which uses Busybox and doesn't have installed by default some of the common commands you could use to solve this (e.g. usermod). It does have chpasswd installed which you can use to set the encrypted password hash to an invalid value (typically *) which prevents password login as this user.

Create a (disabled) account without a password:

adduser -u 1000 -D -s /usr/bin/git-shell tom

Unlock the account and set an invalid password hash with:

echo "tom:*" | chpasswd -e

Answer 6

unlock the account and change the password to some random string