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
    Commented Mar 28, 2015 at 9:28
  • passwd -u is a bad idea. See the answer by Giles bellow. Commented Nov 20, 2015 at 6:52

6 Answers 6


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
  • 14
    Thanks - usermod -p '*' username worked a charm! Commented Jun 11, 2015 at 16:08
  • 4
    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). Commented Nov 28, 2016 at 7:16
  • 3
    I have an embedded system without PAM, so the '*' vs. '!' distinction is super useful.
    – jpkotta
    Commented Mar 2, 2017 at 20:31
  • fwiw this strategy is also discussed at arlimus.github.io/articles/usepam
    – Jeff
    Commented May 14, 2020 at 0:13

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

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

  • 1
    Thanks for the comment about UsePAM. I was confused why the problem kept happening after a reboot. Turns out I had changed UsePAM in a server provisioning script.
    – gluxon
    Commented Dec 31, 2019 at 3:52
  • 2
    UsePAM should always be set to no unless you have a very good reason to use it, like when you set Multi-factor Authentication. Hardening an SSH server always recommends to have it set to no. Read more in this article. See how to set Multi-Factor Authentication with PAM at this guide from Mozilla.
    – Exadra37
    Commented Jan 31, 2021 at 18:08

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

  • I have same environment - Alpine, no usermod, so this worked for me, thanks!
    – Mikha
    Commented Feb 24 at 4:26

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .