Take the 2-minute tour ×

a while ago I gave root a password so I could log in as root and get some stuff done. Now I want to disable root login to tighten security, since I'm going to be exposing my serve to the internet. I've seen several ways of doing this (sudo passwd -l root, fiddling with /etc/shadow, and so on), but nowhere that says what the best/most sensible way of doing it is. I've done sudo passwd -l root but I've seen advice that says this can affect init scripts, and that it's not as secure as it looks since it still asks for a password if you try to log in, rather than flat out denying access. So what would be the way to achieve that?

EDIT: to clarify, this is for local login as root; I've already disabled remote login via SSH. Though trying to log in as root over SSH still prompts for root's password (which always fails). Is that bad?

share|improve this question
Disabling local access for root has almost zero security benefit. A user with physical access can pwn your box in countless ways. –  jscott Sep 4 '10 at 14:45
Point taken. No need to log in as root if you can just take the hard drives out. I'd still like to know how to return the root account to how it was before I changed it though, if only out of curiosity now. –  Ben Hymers Sep 4 '10 at 15:36
see the update to my answer below. I think I now understand what you're asking. –  jscott Sep 4 '10 at 15:52
add comment

7 Answers

up vote 10 down vote accepted

It's debatable, to me, that disabling root is worth the potential issues. I have never tested a server configured in such a manner. My preference is to allow root local access only. If an attacker has physical access to your server, you can forget everything you've done to "secure" your install anyway.

Disable root ssh access by editing /etc/ssh/sshd_config to contain:

PermitRootLogin no

Fiddling with /etc/shadow, chsh -s /bin/false root all can be undone with a simple bootable CD/thumbdrive.

Update per your comment:

From help.ubuntu.com: "By default, the root account password is locked in Ubuntu". Please see the section "Re-disabling your root account" specifically. In order to reset the state of root's account, to install-default, use the following command:

sudo usermod -p '!' root
share|improve this answer
No system is secure when an attacker has physical access to that system . When you can edit /etc/shadow, what stops you from editing /etc/ssh/sshd_config? –  SvW Sep 4 '10 at 14:33
@SvenW: Exactly. That is why I debate the usefulness, security-wise, of even bothering to "disable" root. Restrict root's access, yes. Disable the account, no. –  jscott Sep 4 '10 at 14:38
Brilliant, thanks! Exactly what I wanted. –  Ben Hymers Sep 4 '10 at 15:59
add comment

I assume you refer to remote login via ssh. Add the following line to /etc/ssh/sshd_config:

PermitRootLogin no

and the restart the ssh service

sudo service ssh restart

That should do the job and you can keep your root account as it is (or try to disable it anyway if you feel that is necessary).

share|improve this answer
Sorry, I should have said, this is for local logins. I've updated the question. –  Ben Hymers Sep 4 '10 at 14:38
add comment

Replacing the encrypted password with a * in /etc/shadow (second field, after the first ':') is the best way, IMHO. Also, deactivate root login for ssh (this way it's simply impossible to login via ssh as root) and maybe restrict ssh to certificate logins, which is much more secure than password-based logins.

In most cases, SSH should be the only service accessible from the outside which potentially allows root login, so this door would be locked.

In order to further restrict this, you could install something like fail2ban, which bans IP addresses for a certain amount of time after a number of unsuccessful login attempts.

share|improve this answer
I've a feeling '*' is the same as '!', as per the accepted answer, so I'll vote this answer up too. –  Ben Hymers Sep 4 '10 at 16:00
add comment

The main question has been answered several times, but the secondary has not. SSH prompts for the password after entering root after it is disabled as a security feature. It will also trigger if you try to log in as lkjfiejlksji.

This is to prevent someone from testing a pile of usernames, to try and find out which are valid on your system. However, from a security standpoint, if you've disabled root over SSH, I'd also set up a bruteforce detection program (like fail2ban), and set it so that if someone even tries to log in as root, it blocks them from trying any additional attacks.

share|improve this answer
Good answer, thanks! I've got fail2ban set up already, I'll configure it to block on the first attempt at logging in as root though, good advice. –  Ben Hymers Sep 6 '10 at 8:44
add comment

Re: Security.

IMHO there is only so much you can do, security wise, short of unplugging the box, disconnecting it from the network, and welding it inside a 3" thick bullet-proof carbide-steel box.

Think of it this way - if folks can hack the Department of Defense, the CIA, the FBI, and Citibank - the rest of us mere mortals can't do much better.

Re: SSH security.

I not only forbid root access via ssh, I also set the "AllowUsers" parameter to my, and only my, username. This way nobody but my own user can log in via ssh. This may be redundant as in my own case, I only create ONE non-root user anyway.

Unfortunately, as others have said many times before, as soon as someone gets physical access to the box, all bets are OFF!

Certificate exchange for ssh login? Hmmmm. . . . sounds good. How do you do it?

Jim (JR)

share|improve this answer
add comment

JR et al,

Your AllowUsers led me to this https://help.ubuntu.com/community/SSH/OpenSSH/Configuring

sudo vi /etc/ssh/sshd_config

PermitRootLogin yes (changed to no)

(add line at bottom of file) DenyUsers user1 user2

save and exit and then

sudo service ssh restart

Solved my issue. Thanks to all.

share|improve this answer
add comment

If you want to disable local root login, you can try to modify /etc/passwd and replace /bin/bash by /bin/false. HOWEVER, since I haven't tested it, I would say leave a root session open on the side, test it, and if there is any weird side effect, change it back.

share|improve this answer
add comment

Your Answer


