You locked the password of the account `intern` and confirmed that its hash in /etc/shadow now begins with an exclamation mark. The intern nevertheless still reaches a shell on the host over SSH, without being prompted for anything. What is going on, and what actually stops it?

LPIC-1 Exam 102-500, objective 110. Security hard

Machine-checked — no person has signed for it. This question was read against the source cited below by an automated pass, which found no contradiction. That is a weaker claim than it sounds: the same kind of process wrote the question, so it can confirm its own mistake.

Treat it as a good draft rather than as settled fact, and read the source below before you rely on it. It is not used in mock exams here — only questions a person has signed for are.

How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.

The options

Correct Public-key authentication never consults the password hash, so the key in ~intern/.ssh/authorized_keys still lets the account in; removing that key, or expiring the whole account with `chage -E 0 intern`, is what stops the login.

Correct, and it is the classic trap. Locking only makes the stored hash unmatchable, which defeats password authentication and nothing else. sshd's publickey method authenticates against authorized_keys, so a locked password leaves it untouched. Expiring the account makes PAM's account stage refuse the session regardless of how the user authenticated.

Not correct The lock does not take effect until the account's existing sessions end; `pkill -u intern` applies it.

Wrong. The change to /etc/shadow is effective at the next authentication attempt — there is no deferral. Killing the user's processes ends the current sessions but does nothing to prevent the next key-based login.

Not correct The exclamation mark is honoured only by the local console login program; sshd does not use PAM's pam_unix module at all.

Wrong. sshd does consult pam_unix for password authentication on a normal Linux install, and it is precisely that path the lock blocks. The reason the login still succeeds is that no password path was used.

Not correct Locking left the password field effectively empty, so sshd accepted an empty password; setting `PermitEmptyPasswords no` in sshd_config fixes it.

Wrong. Locking prefixes the hash rather than emptying the field, so the field is not empty — that is what `passwd -d` would do. PermitEmptyPasswords is a real sshd_config directive and defaults to no in any case.

Why

Password locking (`passwd -l` / `usermod -L`) is a password-authentication control, not an account control: it preserves the original hash behind a ! prefix so that unlocking restores it, and it stops nothing that does not check that hash — SSH keys, and any service authenticating some other way. Blocking the account itself means expiring it (`chage -E 0`), removing the authorized_keys entry, or setting the shell to /sbin/nologin, usually more than one of the three.

Where this comes from

Cited
LPI exam objective 110.1
What it says
Understand the limits of password locking when key-based authentication is configured.

Practise this

Reading one question is not practice. The trainer will draw a short set from objective 110 and space the ones you get wrong.

Practise LPIC-1 Exam 102-500

More questions on this objective

All questions on Security

Practise LPIC-1 Exam 102-500