LFCS User and Group Management Practice Question
A junior administrator issued the command 'usermod -L alice' to lock the account of user alice. However, alice is still able to log in via SSH using a public key. What is the most likely reason?
⚠ Common exam trap
Test-takers frequently assume `usermod -L` disables all authentication methods, but it only affects password-based authentication, not SSH public key or other key-based mechanisms.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The usermod -L command only locks the password but does not prevent SSH key-based authentication.
The `usermod -L` command locks the user's password by placing an exclamation mark (!) in the second field of the /etc/shadow file, which prevents password-based authentication. However, SSH public key authentication does not rely on the password field; it uses the authorized_keys file and the SSH daemon's public key challenge-response mechanism. Therefore, even with a locked password, the user can still log in via SSH if their public key is present in ~/.ssh/authorized_keys.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The usermod -L command only locks the password but does not prevent SSH key-based authentication.
Why this is correct
The usermod -L flag prepends an exclamation mark to the encrypted password field in /etc/shadow, disabling password authentication only. SSH public key authentication bypasses that field entirely, so alice's authorised_keys entry still grants access. Locking the account fully requires expiring it or removing the key.
- ✗
The usermod -L command only changes the user's shell to /sbin/nologin.
Why it's wrong here
usermod -L prepends a lock marker to the password hash in /etc/shadow; it leaves the shell untouched. Changing the shell to /sbin/nologin is done with usermod -s or chsh, and even that would not stop key-based SSH access.
- ✗
The usermod -L command requires a restart of the SSH service to take effect.
Why it's wrong here
Locking rewrites the password hash to a locked prefix; sshd does not consult that hash when a public key satisfies authentication, so no service restart changes the outcome. Restarting sshd is relevant when altering sshd_config, not account state.
- ✗
The usermod -L command is not effective on accounts with a UID less than 1000.
Why it's wrong here
usermod -L applies to any local account regardless of UID; the 1000 boundary merely separates system from regular users by convention. The lock fails here because public key authentication bypasses the password hash entirely, so the account still authenticates.
Go deeper
Related to this question
About these practice questions
Courseiva writes every LFCS question from scratch — 406 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LFCS practice question is part of Courseiva's free Linux Foundation certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the LFCS exam.