Ytdyklly

AFAIK, the second field of /etc/passwd can be

• x: password is in shadow


• hashed password

What if I put a string less than 8 chars in the field? I do not want anyone to use password on this account.

If /etc/shadow exists, you should not be using the password hash field of the /etc/passwd file. You should use the equivalent field in /etc/shadow instead.

If you put an invalid string in the password hash field (whether the field that is in active use is in /etc/shadow or in /etc/passwd), password authentication will be disabled. However, putting in a string of non-standard length would be unexpected: I think it's better to use a character that is not used by the password hashing function. A non-standard-length password hash string might be assumed to be a copy/paste error in mass-editing the password file, but using a character that is outside the standard set is clearly deliberate.

You should also know that the meaning of passwd -l was changed.

Before August 2008, the passwd -l <username> command was commonly equivalent of this:

OLDPW="$(grep ^<username>: /etc/shadow | cut -d : -f 2)"

echo "<username>:!$OLDPW" | chpasswd -e

usermod --expiredate 1 <username>

In particular, the passwd command in the shadow source code package did exactly this.

On August 22, the command was changed from "locking the account" to "locking the password only". In other words, after the change the command now did only the equivalent of this:

OLDPW="$(grep ^<username>: /etc/shadow | cut -d : -f 2)"

echo "<username>:!$OLDPW" | chpasswd -e

So it still prefixed the encrypted password with an exclamation mark as before, but no longer also marked the entire account as disabled.

The shadow source code package was/is the upstream source of many distributions' passwd commands, and so the change ended up happening in many distributions. For example, RHEL 5 has the old behavior, but RHEL 6 follows the new one.

Busybox's passwd command has a separate codebase, so I have no idea which behavior they're following. A quick search through BusyBox's documentation seems to indicate it does not include password/account aging functionality at all.

But if you find that running passwd -l <username> also disables SSH key authentication for that user (i.e. the old behavior), you can instead lock the password only by setting it to any value that cannot be produced by the password hashing function. For example, like this:

echo "username:!" | chpasswd -e

This should be a pretty universal way to set an user account to a "non-password-based authentication only" state.

A relatively common convention seems to be to use an exclamation mark (either alone or prefixed to any previous contents of the password hash field) to indicate a locked password, and an asterisk (replacing the entire contents of the password hash field) to mark the account as a system account that is not supposed to be unlockable with passwd -u. However, other authentication mechanisms, like SSH keys, can function even if the password hash field has an invalid value.