When someone leaves or an account is compromised, deleting it immediately can break cron jobs, file ownership, and mail. Start by locking the password, then apply account expiry and check every access method that must be disabled. These commands require root privileges:
sudo usermod -L deploy
Lock the password (blocks password logins)
usermod -L puts a ! in front of the password hash in /etc/shadow, so no password will ever match. passwd -l does the same thing.
sudo usermod -L deploy # lock
sudo usermod -U deploy # unlock
sudo passwd -S deploy # check: L = locked, P = usable password, NP = no passwordImportant caveat: locking the password does not block SSH key logins. If the user has a key in authorized_keys, they can still get in. Account expiry adds an account-level check; verify the actual SSH and PAM configuration as described below.
Block the login shell
Set the login shell to nologin to refuse sessions that invoke that shell. Record the original shell before changing it:
sudo usermod -s /usr/sbin/nologin deploy # block
sudo usermod -s /bin/bash deploy # restore only if /bin/bash was the original shellA login shell setting is not a universal access revocation mechanism. Check services such as internal SFTP and forwarding separately, revoke credentials where required, and deal with existing sessions through your offboarding or incident procedure.
Expire the account entirely
To disable an account on or after a date (or right now), expire it:
sudo chage -E 1970-01-02 deploy # unambiguously in the past
sudo chage -E -1 deploy # remove account expiry; other restrictions remainAvoid chage -E 0: shadow(5) documents that zero can mean either no expiry or 1970-01-01. Account expiry can reject new password and key logins when the service enforces local account checks, including SSH with the appropriate PAM account configuration. Verify a new login attempt while keeping a separate administrator session open. This does not terminate existing sessions or revoke independent application tokens. See set password expiry and account aging for the full chage reference.
FAQ
Not reliably. usermod -L and passwd -l invalidate the password; a user with a key in authorized_keys can still log in. For account-level expiry, use an unambiguous past date such as chage -E 1970-01-02 deploy and verify that the relevant SSH/PAM configuration enforces it. A nologin shell rejects sessions that invoke that shell; check other services and existing sessions separately.
sudo passwd -S deploy prints the status: L means locked, P a usable password, NP no password set. You can also look for a leading ! on the hash in /etc/shadow.
Lock first. Deleting immediately can break cron jobs, leave orphaned files, and lose the audit trail. Lock the password, set nologin, and only delete the user once you have confirmed nothing depends on the account.
See also
- How to Delete a User on Linux: when locking is no longer enough.
- Set password expiry and account aging (chage): account expiry and how SSH/PAM account checks affect key logins.
- Force a password change at next login: a softer control for a suspect password.
- How to change a user password (passwd): the passwd states behind -S.
- How to Give a User sudo Access on Linux: the opposite move, granting an account admin rights rather than locking it out.
Sources
Authoritative references this article was fact-checked against.





