51

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?

Braiam
  • 35,380
  • 25
  • 108
  • 167
  • 3
    Are you planning on re-enabling it eventually? System lockdowns? If not, I'd simply remove the account. – Ken Feb 20 '11 at 02:30

6 Answers6

64

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.)

Explanation:

  • --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>
Sergei G
  • 103
  • 2
Christoph Wurm
  • 5,678
  • 5
  • 25
  • 28
  • 7
    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 – Marcus Maxwell Sep 01 '14 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 '14 at 09: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 '16 at 21:58
  • 3
    Why is `--expiredate 1` not enough on its own? – Thomas Jensen Aug 13 '17 at 10:26
  • But `sudo su username` seems to work using another account. – xuhdev Sep 14 '17 at 04:48
  • Why do we need `--lock`? – xuhdev Sep 17 '17 at 19:27
  • This method is largely useless because the user could have created a public key login previously. – MikeKulls Oct 11 '17 at 01:25
10

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.)

mattdm
  • 39,535
  • 18
  • 99
  • 133
  • How do i 'change the shell to /bin/nologin.'? –  Feb 20 '11 at 03:47
  • @acid Just edit `/etc/passwd`: look for that user's line and change for example "/bin/bash" to "/some/invalid/path". – phunehehe Feb 20 '11 at 04:05
  • 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 '11 at 04: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 '11 at 13:56
  • @mattdm The man page says "If command is specified, it is executed on the remote host instead of a login shell." My apologies, I was wrong, that's not what happens. – phunehehe Feb 20 '11 at 14:59
  • I would delete that embarrassing comment, but leave it here so as not to break the conversation. – phunehehe Feb 20 '11 at 15:02
  • 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 '11 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 '11 at 21:42
  • `/sbin/nologin` will work too, for different reasons. That'll print out something like "This account is currently not available" and exit. On the other hand, `/bin/nologin` will, with openssh, restrict access because the file _doesn't_ exist. – mattdm Feb 20 '11 at 22:08
  • I'll update my answer with practical "what to do" steps. – mattdm Feb 20 '11 at 22:08
9

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.

miklosq
  • 130
  • 1
  • 5
4

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.


So...

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!

user1880028
  • 41
  • 1
1

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

700 Software
  • 487
  • 5
  • 16
  • 1
    google authorized_keys or try reading this http://www.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 –  Feb 20 '11 at 03:50
0

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.

icasimpan
  • 439
  • 6
  • 16