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]
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 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
Method 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
Method 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
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.)
Method 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/
Method 5
unlock the account and change the password to some random string
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0