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
Draft — not checked yet. This question was written from the published exam objectives and cites the clause it comes from, but nobody has yet read it against that clause and signed for it.
It is kept out of search results and out of mock exams until they have. Read the source below before you take the answer as settled.
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 set from objective 110 and space the ones you get wrong.