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]
  • you should (IMHO) do this for all users ... a simple config when doing it for the whole sshd – Skaperen Mar 28 '15 at 9:28
  • passwd -u is a bad idea. See the answer by Giles bellow. – Peter Jenkins Nov 20 '15 at 6:52

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
  • i got the impression Miro wanted to disable password for just one use. but see my earlier comment – Skaperen Mar 28 '15 at 9:38
  • @Skaperen - you could well be right. I've altered my answer slightly. – garethTheRed Mar 28 '15 at 9:47
  • That Match syntax looks good, but I'm gonna try it reversed. Enable password-ed login for (few lame) users. – kravemir Mar 28 '15 at 10:34
  • @Miro - That's a good idea, I've added it to my answer for future reference. – garethTheRed Mar 28 '15 at 10:57

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
  • 4
    Thanks - usermod -p '*' username worked a charm! – Homme Zwaagstra Jun 11 '15 at 16:08
  • 1
    OpenSSHd does allow locked users (i.e. password hash with ! prefix) to login with some other authentication method if UsePAM yes is set in sshd_config. This is probably the default with most distributions (e.g. with Fedora). – maxschlepzig Nov 28 '16 at 7:16
  • 1
    I have an embedded system without PAM, so the '*' vs. '!' distinction is super useful. – jpkotta Mar 2 '17 at 20:31

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

In general, unless you have a really good reason to disable PAM, I recommend you keep it enabled; 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 messing with SSH: 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 current session to fix it.

(Disclaimer: I work at Userify, which provides SSH key management software.)


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/


unlock the account and change the password to some random string

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.