Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am making a web server running LAMP and want to access it using SSH.

When I open the passwd file, I see all those accounts and I want to know for which ones I can put false. I have the following accounts:

root, daemon, bin, sys, sync, games, man, lp, mail, news, uucp, proxy, www-data
backup, list, irc, gnats, nobody, libuuid, syslog, messagebus, whoopsie, 
mandscape, sshd, eric

Except root, sshd and eric, which ones should I not disable? How about www-data and sshd?

share|improve this question
Note: the sshd account was set to nologin shell, and yet I was able to connect to SSH normally. - As the sshd user? – MDMarra Sep 19 '12 at 2:07
@MDMarra Wondering about that also, how would OP get the password for user sshd without resetting it? – jscott Sep 19 '12 at 2:20
@jscott I'm assuming that OP just doesn't understand how those accounts work and what setting the default shell actually does, but it doesn't hurt to make sure. – MDMarra Sep 19 '12 at 2:24
Hi, yes I'm a beginner, and have searched various ways of securing the server. Locking those accounts, being one of them. Regards – ericd Sep 19 '12 at 2:35
Why is there even an account named "games"? This isn't on a server, is it? – John Gardeniers Sep 19 '12 at 5:47
up vote 5 down vote accepted

You have a few misconceptions, both on how the login system works and what the purpose of these accounts is.

First, most of these accounts, with the exception of root and eric, are system accounts that are not meant for people to login but allow different services to run as ordinary users without all the privileges the root account has. As an example, the OpenSSH daemon usually runs as user sshd, so if anyone would manage to gain control over the sshd process, it would allow him only to access and modify the files for which the corresponding user sshd has permissions.

Second, the preferred way to disable login for a user is to disable his password and not to change the login shell to /bin/false. On modern Linux systems, the user database actually consists of two parts, /etc/passwd and /etc/shadow. The password is stored in /etc/shadow (see below for why), and an account is disabled if its password field in /etc/shadow is an *.

In the following example, the user sshd is disabled, while sven has an encrypted password set. You can't login as user sshd, neither via the console nor an ssh session, but login for sven will work.


Most likely, you will find that all users on your system, with the exception of eric (and maybe root) are disabled this way, which means that what you want to accomplish has already been done by the developers. Also, you will find that many accounts also have their login shell already set to /bin/false in /etc/passwd, which means that even root can't use `su' to switch to these accounts.

Why the separation of /etc/passwd and /etc/shadow?

Many programs need to access the user database for various purposes, but giving read access to /etc/passwd allowed everyone to read the encrypted passwords of all users, which is highly insecure, especially as the encryption of the passwords was quite weak for a long time. This was solved by putting the passwords into the separate file /etc/shadow, which is only readable by root.

share|improve this answer
Hi there, thanks a lot for your detailed and clear response. Regards – ericd Sep 19 '12 at 15:43

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.