I have recently found an argument against disabling a root user login in Linux at http://archives.neohapsis.com/archives/openbsd/2005-03/2878.html

I assume that, if everybody uses a public key authentication, there's no risk at losing the root password.

Is it always better to disable the root login via ssh?

  • 1
    What you really need to be asking is "Does disabling root login comply with my security policy?" Everyone's policy is different for various reasons. – Alex Holst Apr 30 '10 at 20:22

The short answer is that the smaller your attack profile the better. Always. If you don't need it or can use an alternative such as sudo or su, then don't enable root login.

One big argument in favor of disabling root and using sudo/su is that you can track who's doing what. One user - one login. Never share accounts.

The argument at that link seems to be specific to local login, rather than ssh.

  • 3
    The tracking point is moot: sudo -i, and your actions show up as root's, not yours – Fahad Sadah Apr 30 '10 at 15:07
  • 2
    But you have the record of their original login. You may not have proof, but you have evidence. Plus you can control what the user has access to and can do. – Dennis Williamson Apr 30 '10 at 15:37
  • What about one user per os situation? There is only one person manage the system, I can track who doing what already. Use sudo make the bash string escape very complex... for example: unix.stackexchange.com/questions/551899/… – bronze man Nov 13 '19 at 10:49

I second Dennis´ point, plus:

Allowing root login via SSH also means root is attackable by brute force password guesses.

Because root is always there, and the reward is so high, it is a priority target. The username would have to be guessed first, which adds a few orders of magnitude to the difficulty of the problem.

  • Also, because it's root, as with most admin accounts, even if you set your system to lock accounts after (x) failures, it won't. You instead have to set up something to block IPs after failures, but even that won't help against a distributed brute force. – Joe H. Apr 30 '10 at 14:35
  • 1
    You can rename the root account, just like any other. – Fahad Sadah Apr 30 '10 at 15:07
  • @fahadsadah Some software assumes UID 0 == root. I once tried renaming root on an OpenWRT router and its web interface broke. – Gerald Combs Apr 30 '10 at 21:01
  • 3
    Root via ssh does NOT automatically mean that the system is susceptible to brute force. Consider a system with the PermitRootLogin without-password option set. – Zoredache Jun 17 '10 at 22:40

Never disable the root account if you don't have console access. If your filesystem fills up and the boot fails while /etc/nologin is created, only the root account will be allowed to login into the machine.

That said, if you have console access to deal with these situations, closing root account may save you some headaches, as no one will be able to get to the root account using a dictionary attack (my experience is that these are constant these days - someone is always trying). Other things you might think of doing:

  • Install a program like fail2ban that automatically closes access to an IP address if it fails authentication more than a number of times (to actively protect against dictionary attacks).
  • Only use ssh keys.
  • If you manage a lot of machines, use cfengine or other to manage the public keys that you authorize to enter a machine (or else you get those outdated pretty quickly).

Best regards,
João Miguel Neves


It is always better to disable root login via SSH.

There are PKI systems (e.g. public keys with SSH) that have been compromised. SSH has already had remote authentication flaws previously that enabled a root compromise to occur. Software PKIs are notoriously weaker than hardware based PKIs.... if your host computer is compromised, the target server could likewise fall easily. Or there could be novel flaws found in SSH. By limiting root login, you could also extend the period of time an attacker needs in order to perform privilege escalation.

Historically, many administrators used bastion hosts (basically gateways) in order to enter a network, and then jump to boxes afterward. Using a high secure distro (e.g. OpenBSD) as a bastion host, in conjunction with different operating systems provides defense-in-depth and defense-in-diversity (one vulnerability less likely to compromise entire network).

Please consider having an out of band connection to your network also, such as a serial concentrator, serial switch, or other. This will provide backup availability of your administrative interface if required.

Because I am paranoid and in security, I'd be more likely to use an IPSEC VPN or Type1 VPN, and then run SSH on top of it, with no internet exposure of SSH whatsoever. Putting the VPN on your network hardware can dramatically simplify this in implementation.


We should examine this question from different points.

Ubuntu disables the root account by default, which means that you can't login via SSH with root. But, it allows anyone with an Ubuntu CD can boot and get root access.

I believe the best compromise is to enable the root account with disabled SSH access. If you need root access with SSH, login with a normal user and use sudo. This way it secures access to the box, without compromising remote security.

  • 2
    By the time someone is booting your machine with a CD it's already too late, they've already pwned your machine. The best you can hope for then is an encrypted data partition. – Kamil Kisiel Apr 30 '10 at 15:06
  • 1
    If you have access to the "cup holder", you don't need ssh. – Dennis Williamson Apr 30 '10 at 15:38
  • @Kamil Kisiel that doesn't mean you can't put up road blocks to deter them. Whats the phrase? If they can touch your box, they can own it. But, we need to put things into perspective. @Dennis Williamson can you explain your comment further? – Natalie Adams Apr 30 '10 at 22:54
  • What road blocks? If you're booting off your own CD, you don't need any passwords. You just read the filesystem. – Kamil Kisiel May 1 '10 at 5:02

I'd say yes, login as root should be disabled for auditability. If you are the sole system administrator on this machine, it's trivial to determine who did what to whom, but if ten people are authorized to administer the box and they all know the root password we have a problem.

Whether or not root is enabled, neither root nor any other user should be permitted to login remotely with a password. fail2ban won't do anything against a slow brute-force botnet, and doesn't work at all with IPv6. (ssh protocol version 1 and older implementations of version 2 were vulnerable to password-guessing attacks against interactive password prompts within the ssh session, but this appears to no longer be the case with a sufficiently recent ssh implementation.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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