Account locking and passwordless SSH

One of the nice things about SSH is passwordless login. However that doesn’t mean that passwords can’t ruin your day. Let’s assume you have an account on a system you exclusively use with passwordless SSH. And it worked flawlessly. One day you try to login to your system and the login doesn’t work.

jmmac@waddledee .ssh % ssh jm3@192.168.x.y
Connection closed by 192.168.x.y port 22

However you really changed nothing on the system. No new keys. No new configuration. So what happened? Well, you use a different account on the system and find the following line for your account in /etc/shadow:

jm3:*AL*$5$rounds=10000$f(..)Az/:20124::::::7071

Your account has been autolocked, hence the AL at the beginning of the password field. You remember that you have activated locking of accounts after a certain number of failed attempts. But you use passwordless login, how could the account get in the autolocked state? Well, just because you didn’t entered the wrong password this doesn’t mean that other people can’t try to get into your account by trying out passwords. At the end the whole account locking feature after some failed attemptes is a feature to keep other people out of the system, not you. Albeit in practice i concede there are a lot of people kept out of their own systems because of a cookie problem. Like the author of this blog entry. ¹

So let’s simulate such an ill-fated attempt.

jmsol@testbed:~$ ssh jm3@localhost
(jm3@localhost) Password: 
jm3@localhost: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
jmsol@testbed:~$ ssh jm3@localhost
(jm3@localhost) Password: 
jm3@localhost: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
jmsol@testbed:~$ ssh jm3@localhost
(jm3@localhost) Password: 
jm3@localhost: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
jmsol@testbed:~$ ssh jm3@localhost
(jm3@localhost) Password: 
jm3@localhost: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
jmsol@testbed:~$ ssh jm3@localhost
(jm3@localhost) Password: 
jm3@localhost: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

With LOCK_AFTER_RETRIES set to yes or a similar per-user policy, the system behaves according to configuration after such attempts and locks the account. Okay, let’s go to the admin and ask for an unlock.

root@testbed:~# passwd -u jm3
passwd: password information changed for jm3

Now it works again.

jmmac@waddledee .ssh % ssh jm3@192.168.x.y
Last login: Wed Feb  5 08:19:08 2025 from 192.168.x.z
Oracle Solaris 11.4.76.182.1                  Assembled December 2024

Well, how you can prevent this from happening again? If you are sure that you don’t need to login with a password, you can set the account into a state where logins with passwords are disabled for this account. The nescessary option was introduced in Solaris 10 3/05 … so this is almost 20 years old.

root@testbed:~# passwd -N jm3
passwd: password information changed for jm3

This puts the account in the NL state:

root@testbed:~# cat /etc/shadow | grep "jm3"
jm3:NP:20124::::::

root@testbed:~# passwd -s jm3
jm3       NL    

An account in the NL state is a non-UNIX authentication account. Despite entering the correct password, it doesn’t let me in:

root@testbed:~# ssh jm3@localhost
(....)
jm3@localhost's password: 
Permission denied, please try again.
jm3@localhost's password: 
Permission denied, please try again.
jm3@localhost's password: 

Furthermore it behaves differently in regard of failed login attempts with wrong password. It doesn’t lock. No matter how often you try with a wrong password. But that’s okay, because you can’t login with a password into such an account at all. But someone else can’t lock your account as a collateral effect by trying passwords.