Should we remove the root password, disable remote login and basically require adminstrators to use sudo to perform administrative actions?

alt text

9 Answers 9


All my servers have the root account disabled (sp_pwdp set to *). This is to require sudo for all root access.[1] The purpose of this is to have all superuser activities audited, so people can see what has been done to the system.

For a more hardcore option, you can make sudo write to a log file (as opposed to syslog), and make the file append-only (using chattr on Linux, or chflags on BSD). This way, nobody can edit the audit afterwards.

[1] I also have a policy of not running a root shell, or doing shell escapes from a root process. (It's okay to use sudo sh -c '...' for doing pipelines or redirections, though.)

  • 3
    "No running of shells, either!" Uhm, do you know how many programs have a "drop to shell" command in them? Even before you start looking at shell job control...
    – womble
    May 2, 2009 at 2:29
  • I'm talking about "no shell" as a policy, not as a sudo option. (sudo does have a noexec option, but obviously that's not watertight unless you restrict the specific programs that a user is able to run.) May 2, 2009 at 2:33
  • Is it possible to configure sudo so that "sudo -s" can't be used? I've only used sudoers to configure individual commands.
    – user448
    May 2, 2009 at 9:06
  • @Graham: You can. However, as you can see from the comments above, that doesn't stop anything, if your users can otherwise run anything. The only watertight solution is a whitelist approach, where you list specific program that users can run, and they must all be dynamically linked (so that the "noexec" option can do its thing). May 2, 2009 at 14:03
  • As a policy where you trust the admins this is good. You can see what commands people run which can be really helpful when trying to work out what has changed. May 2, 2009 at 16:57

I emphatically recommend against disabling the root user. Disable or restrict root logins (via securetty and via sshd_config and via PAM and via what have you) If your system permits it, limit root's privileges or split up the root role (akin to how RSBAC does it.) But please, please, do not disable the root account by removing the password, otherwise it will become impossible to log into the system via sulogin. sulogin is used by all initscripts I know in case of serious errors reported by fsck - and that means you will be locked out of the system if the root file system gets corrupted.

To clarify: By "disabling the root account by removing the password" I mean the various mechanisms that end up with a ! or a * in the password field of /etc/shadow, or similar. I do not mean "change the root login mechanism so you don't get prompted for a password."

  • Is this a problem in systems like Ubuntu that never set a root password? I seem to be able to execute "sudo sulogin", but perhaps I don't comprehend a critical aspect.
    – jldugger
    May 2, 2009 at 22:48
  • Unfortunately I'm not familiar with the way Ubuntu handles root. But if you're able to do "sudo sulogin" and get a root shell without being prompted for a root password, then no, it's not a problem, since conceivably the same mechanism will apply at boot. You could try looking grepping for sulogin through the initscripts to check when and how it's invoked. May 2, 2009 at 23:51
  • 1
    Ubuntu doesn't use sulogin. If you go into single-user mode you get a root shell straight away. However, read my comment (in my post) to see why this isn't a problem, in most cases. May 4, 2009 at 4:12
  • Besides, there are claims that having su or sudo in your system available to users means more security risks you can avoid if you have only dedicated root users. That's a position advocated by the authors of the Owl secure distribution (and Solar designer among them) -- unix.stackexchange.com/questions/8581/… tries to present their position with references. May 21, 2011 at 5:10
  • I just had this very problem: I locked my root user and a fsck was forced because of a hard reset. Luckily I could boot my faulty Linux with the fastboot option, unlock the root account and restart to finally run fsck manually.
    – tommyd
    Dec 9, 2013 at 21:38

I have the root account enabled on all my servers. All the administrators have their own user and have to log in through that. From there they switch to root. (root ssh is disabled)

Keep the administrator count low. Only the people that really need root access on that server have the password.

I'm not a fan of sudo. It's way too easy to just do 'sudo bash' for a root shell. I'm aware this can be disabled but why bother? Just limit the users that can perform administrator tasks and talk to eachother. We do have a policy to not let root terminals open unattended. So it's log in, su, do the work, log out.

Note: I work at a fairly small company (50-something employees) and we get around with only 2 part-time admins (1 windows/1 linux). This way of doing things might not be the best when you have orders of magnitude more users. I'd personally still wouldn't use sudo. There are other ways to log root activity.

  • If you want root shell from a console you could just do 'sudo -i' instead of opening it from sudo bash. Personally I really don't like the idea of logging in as root user directly since it is too risky for malicious goating (i.e. accidentally leaving the computer unlocked with the root shell open).
    – Spoike
    May 2, 2009 at 8:44
  • You lose logging/auditing with that, though. Make everyone use sudo, and prohibit people from doing sudo bash, or sudo -i, or sudo -s with corporate policy. That gives you an audit trail, and if you are pushing all your logs to a central loghost, it because easy to verify that people are following the policies. May 16, 2009 at 0:26
  • That's the approach taken and advocated by the authors of the Owl secure distribuion (and Solar designer among them) -- unix.stackexchange.com/questions/8581/… tries to present their position with references. May 21, 2011 at 5:06

Disabling root password is imho a false "good idea". The day you will need it, you will really need it. (according to your configuration you might need it to log in single user mode for exemple)

Disabling root remote login might be relevant but only if you are able to log on locally.

And yes, sudo should installed on every one of your servers. It is usefull and easy to configure. Why would you like to not use it?

  • What if booting into single user mode is a grub option?
    – jldugger
    May 29, 2009 at 18:25
  • What is the aim of disabling the root account? What will you do if your brake your sudo binary or configuration (or whatever tool you use)?
    – Benoit
    May 29, 2009 at 20:17
  • Disabling root remote login might be relevant but only if you are able to log on locally. This is just blatantly false. You can log in remotely with any account; disabling root remote login does not limit you to local access.
    – Dan
    Apr 23, 2015 at 18:18

I just disable SSH access for root and require users (often is just developers) to use ssh keys. There's just too many dictionary attacks and changing the SSH port is not an option for us.

That way you don't have to trust in anyone's ability to write a good password. Once inside just the admins have permissions for sudo.

  • Changing SSH port is pointless anyway. A simple portscan gives it away easily. When I telnet to port 22 on my machine, I get SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2 May 29, 2009 at 18:32
  • 3
    @MattSimmons Yes, but most dictionary attacks are automated and very elementary. They don't bother with port scanning; they attempt to connect to random IP addresses on port 22 and if they timeout they move on to the next IP in their list. It's not a security measure, it just helps get rid of the automated port 22 attacks. Obviously a targeted attack is a whole different ballgame.
    – Dan
    Apr 23, 2015 at 18:16

I know this thread is really old but there are some major flaws in the linked articles logic and I'm feeling "rant'ie" - sudo allows both whitelisting and blacklisting. Not just black as they specify in the linked article - This skips over the idea of AAA (Authentication, Authorisation & Auditing) - su & sudo allow for both graded authentication and accountability.

Scenario 1 An administrator accidentally introduces some rogue code to a system, logged in as root the code has complete access and the administrator may never know whats happened. At least with graded logins (e.g. su/sudo) the administrator would be prompted to authenticate if the rogue code tries to use elevated rights... If it doesn't elevate then its confined to the users rights which should result in minimal damage.

Scenario 2 A rogue administrator wants to get info/make a change. They connect to the console (physical console access, HP iLo/similar, or vGuest console access), login as root and do whatever they wish. Unless there is a named account/access card used to gain console access there is probably not much of an audit trail.

  1. Make sure they really are who they say they are. Identity theft isn't the issue, identity verification is.
  2. Check their authorisation, only give them what they need at that time. Graded authorisation allows them to elevate when they need it.
  3. Audit it all, have a record so you know who, did what, when and where. Preferably why as well

You should require everyone to use sudo for every root command as a policy. There is never a reason to run "sudo bash" or the like, it is only for convenience, due to ignorance, or to cover one's tracks.

If you disable logins to the root account directly, you cripple your ability to fix the system when there are severe problems.

If you can't convince your admins to log in as themselves and run sudo for every command run as root, and to not break out of it into a shell, you have serious problems for which there is no technical solution.


The authors of Owl secure distribuion (and Solar designer) have an opposite carefully justified point of view; see, e.g., the answer https://unix.stackexchange.com/questions/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 for a presentation of their claims. The problem of auditing the superuser actions (which person did what) is also addressed in their point of view (basically, the solution is to have several root users with different names).


As long as the root password is secure, there is no advantage of disabling root.

You may want to use sudo on most cases, to avoid mistakes.

But root is convenient when you have to do multiple consecutive tasks that require system permissions.

Such, for example, recovering a system that no longer boots. Or unlocking an user itself.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .