The account needs to stop logging in, but the files must stay
You are managing a shared Fedora workstation or a small internal server. A contractor finishes their project, or you suspect a service account has been exposed to an unauthorized network. You need to cut off access immediately. Deleting the account with userdel wipes the home directory, breaks file ownership, and drops any scheduled jobs that depend on that UID. You need a surgical switch that stops authentication while leaving the filesystem and user identity intact.
Locking the account is the standard procedure. It changes a single character in the shadow file and tells the authentication stack to reject every password attempt. The user stays in the system. Their files stay untouched. Their cron jobs keep running under their UID. Only interactive and password-based logins get blocked.
What actually happens when you lock an account
Linux does not store passwords in plain text. The system keeps a hashed version of the password in /etc/shadow. Each line in that file belongs to a user, and the second field holds the password hash. When a user types a password at the login prompt, PAM reads that hash, runs the input through the same algorithm, and compares the results.
Locking an account does not delete the hash. It prepends an exclamation mark to the beginning of the hash field. The authentication library sees that leading !, recognizes it as a lock marker, and refuses to compare the password at all. The system returns a generic authentication failure. Unlocking the account simply strips that marker and restores the original hash.
This mechanism lives entirely in the password field. It does not touch SSH keys, certificate authentication, or passwordless sudo rules. If your security policy requires a complete shutdown of all access vectors, you will need to adjust additional configuration files. For standard password logins, the shadow file marker is all that matters.
Think of the shadow file like a physical key cabinet. Locking the account does not throw away the key. It places a steel bar across the drawer. The key still exists. The drawer still exists. The bar just prevents anyone from pulling it open. Removing the bar restores access instantly.
How to lock and unlock the account
Run the lock command from a terminal with root privileges. The usermod utility handles the shadow file modification safely and updates the database atomically.
sudo usermod -L jdoe # Prepends ! to the password hash in /etc/shadow
The command returns silently on success. If the account is already locked, it prints a warning but does not fail. You can run it repeatedly without breaking anything.
When the contractor returns or the security incident is resolved, strip the marker to restore access.
sudo usermod -U jdoe # Removes the leading ! from the password hash
Verify the change immediately. The passwd utility includes a status flag that reads the shadow file and prints a human-readable summary.
sudo passwd -S jdoe # Queries /etc/shadow and prints current lock state
Check the second field of the output. It will say L for locked or P for password set. Run the status check before you walk away from the terminal.
Verify it worked
The status command gives you a quick snapshot, but you should confirm the lock actually blocks authentication. Attempt a login from a separate terminal or SSH session. The system will reject the credentials and log the event.
journalctl -xeu sshd # Shows recent SSH authentication attempts with explanatory context
Look for lines containing Failed password or authentication failure. The x flag adds PAM explanations and the e flag jumps to the end of the journal. Most sysadmins type this muscle-memory style when debugging login issues. If you see successful logins after running usermod -L, your PAM stack is misconfigured or you are using a cached credential. Flush the cache and retest.
You can also inspect the shadow file directly to confirm the prefix. The file is readable only by root.
sudo grep jdoe /etc/shadow # Displays the raw shadow entry for the target user
The second field should start with !$y$ or !$6$ depending on your hash algorithm. If you see !! instead, the account was created without a password and the lock marker was applied to an empty field. That state behaves identically for authentication purposes. The account remains locked.
Check the journal before you assume the lock failed. Half the time the symptom is a cached session or a misread log line.
Common pitfalls and what the error looks like
The unlock command will refuse to run if the account has no password hash to begin with. This happens frequently with service accounts created via useradd -r -s /usr/sbin/nologin. The system prints a clear refusal:
usermod: unlocking the user's password would result in a password-less account.
The error is protective. Stripping the lock marker from an empty field would create an account that accepts any password. You have two paths forward. Assign a real password with sudo passwd jdoe, or explicitly set the field to an invalid placeholder that stays locked.
sudo usermod -p '*' jdoe # Sets the hash field to * which permanently disables password login
Another common confusion involves SSH key authentication. Locking the password hash does not disable public key login by default. OpenSSH checks the PasswordAuthentication directive and the PubkeyAuthentication directive independently. If you need to block SSH entirely, add the username to /etc/ssh/sshd_config under DenyUsers or change the login shell to /usr/sbin/nologin. The shadow file lock only stops password-based authentication.
Watch out for systemd user services. If the locked user runs background daemons via systemctl --user, those services continue running. The lock only affects new authentication attempts. Existing sessions remain active until the user logs out or the terminal closes. Kill lingering processes if you need an immediate teardown.
Never edit /etc/shadow manually with a text editor. The file uses strict field separators and permission bits. A misplaced space or a dropped newline breaks PAM entirely. Use usermod or passwd to modify it. The utilities handle locking, atomic writes, and database synchronization automatically.
Trust the package manager and the user utilities. Manual file edits drift, snapshots stay.
When to use this versus other account controls
Use usermod -L when you need a reversible password lock that preserves the original hash for future restoration. Use passwd -l when you prefer the traditional password utility syntax, which performs the exact same shadow file modification. Use usermod -s /usr/sbin/nologin when you want to block all interactive shells while still allowing password authentication for specific services. Use chage -E 0 when you need to expire the account at a specific timestamp rather than locking it indefinitely. Use userdel when the account is permanently retired and you are ready to remove the home directory and group memberships.
Pick the tool that matches the exact boundary you need to enforce. Password locks are reversible and targeted. Shell changes are broader and affect every login method. Account expiration is time-bound and self-cleaning.