How do I completely disable an account? passwd -l will not allow anyone to log into an account using a password but you can still log in via private/public keys. How would I disable the account completely? As a quickfix I renamed the file to authorized_keys_lockme. Is there another way?

  • 3
    Are you planning on re-enabling it eventually? System lockdowns? If not, I'd simply remove the account.
    – Ken
    Feb 20, 2011 at 2:30

6 Answers 6


The correct way according to usermod(8) is:

usermod --lock --expiredate 1970-01-02 <username>

(Actually, the argument to --expiredate can be any date before the current date in the format YYYY-MM-DD.)


  • --lock locks the user's password. However, login by other methods (e.g. public key) is still possible.

  • --expiredate YYYY-MM-DD disables the account at the specified date. According to man shadow 5 1970-01-01 is an ambiguous value and shall not be used.

I've tested this on my machine. Neither login with password nor public key is possible after executing this command.

To re-enable the account at a later date you can run:

usermod --unlock --expiredate '' <username>
  • 8
    Don't use 1970-01-01 as it will set /etc/shadow expiration field to 0. shadow(5) The value 0 should not be used as it is interpreted as either an account with no expiration, or as an expiration on Jan 1, 1970. Please use: usermod --lock --expiredate 1970-02-02 <username> Sep 1, 2014 at 10:52
  • 5
    It would be great if you could also provide the method to reverse this operation. Looks like usermod --unlock --expiredate '' username will do it.
    – Bob
    Oct 22, 2014 at 9:39
  • 3
    Adding to what @MarcusMaxwell wrote: The man page for usermod says: Note: if you wish to lock the account (not only access with a password), you should also set the EXPIRE_DATE to 1.
    – Zero3
    May 22, 2016 at 21:58
  • 3
    Why is --expiredate 1 not enough on its own? Aug 13, 2017 at 10:26
  • But sudo su username seems to work using another account.
    – xuhdev
    Sep 14, 2017 at 4:48

Lock the password and change the shell to /bin/nologin.

sudo usermod --lock --shell /bin/nologin username

(Or more concisely, sudo usermod -L -s /bin/nologin username.)

  • How do i 'change the shell to /bin/nologin.'?
    – user4069
    Feb 20, 2011 at 3:47
  • 6
    @mattdm This is not a complete solution, as a user can still specify a command to be executed. For example ssh username@hostname /bin/bash will give the user a bash prompt, regardless of the default shell.
    – phunehehe
    Feb 20, 2011 at 4:07
  • 4
    @phunehehe — have you tried it? You'll get, in the log, "User [username] not allowed because shell /bin/nologin does not exist".
    – mattdm
    Feb 20, 2011 at 13:56
  • 2
    As far as I know, the invalid-shell behavior isn't actually documented. On the other hand, the man page says that if the password is has a leading !! on Linux the account will be treated as locked, and that doesn't actually work. So, y'know, documentation and reality are only approximate matches anyway. :)
    – mattdm
    Feb 20, 2011 at 15:35
  • 2
    sudo chsh -s /bin/nologin would be better than editing /etc/passwd by hand. Also, on some systems, it's /sbin/nologin.
    – Mikel
    Feb 20, 2011 at 21:42

Here is another simple way. You can set the user account expired. This will prevent both password-based and ssh key-based logins for the account, but does not touch the password.

To lock the account:

# chage -E 0 username

The user account 'username' will be locked out on the system. To re-enable the user account, do the following.

To unlock the account:

# chage -E -1 username

The user account 'username' will be re-enabled on your system with the same password as before. The 'chage' binary is part of the shadow-utils package on Red Hat Linux, or the passwd package on Debian Linux.


I don't have sufficient rep to comment on Legate's answer, but I wanted to share that this answer helped us with another use case:

1.) account in question is a local service account running an application, not an end user account.

2.) end users ssh in as themselves, and sudo /bin/su <user> to become user and administer application due to an audit trail requirement that service account cannot have direct login ability.

3.) service account must have a valid shell (/bin/bash, not /sbin/nologin), because an Enterprise Scheduling Platform (agent runs as root locally) must be able to su - <user> and does not have the su -s /bin/bash <user> ability that a full shell does, and is needed to run jobs remotely for larger batch operations that encompass multiple servers and databases.


passwd -l <user>
Doesn't satisfy constraints because public key authentication bypasses PAM and still allows direct login.

usermod -s /sbin/nologin <user>
Doesn't satisfy constraints becausebreaks the enterprise scheduler

usermod --lock --expiredate 1970-01-01 <user>
This is our winner. Remote login disabled, yet root can still su <user>, as can other users via sudo so the scheduler functions properly and authorized end users can become the target service account as needed.

Thank you for the solution!


To delete entirely it use userdel.

Please note that if you delete an account there is a risk that its user ID will still be used in the file system somewhere and a new user would inherit ownership of those files if it came in under that same user id.

You would want to change the owner of any files that are owned by the deleted user.

If you would like to add the user back later, save its lines from /etc/passwd (and on Solaris /etc/shadow) to temporary files such as /etc/passwd_deleted.

That way when you add it back you can use the same user id and the same password (which is encrypted in one of the above files)

Disclaimer: I learned UNIX on my own so I would not be surprised if there is a better way to temporarily disable the user. In fact I don't even know what the private/public keys are you are talking about. Also I am sure there is a find command that can be used for looking up the files with that owner userid

  • 1
    google authorized_keys or try reading this eng.cam.ac.uk/help/jpmg/ssh/authorized_keys_howto.html basically instead of using a password, you put your publuc key in that file and when you connect with ssh you will automatically be logged in if the one of the public matches your current private key
    – user4069
    Feb 20, 2011 at 3:50

Has anyone tried doing it via ssh_config? Maybe this could help http://www.techrepublic.com/blog/opensource/set-up-user-accounts-quickly-and-securely/86

Also, ensure that PasswordAuthentication is set to no as well, to force all logins to use public keys.

You must log in to answer this question.