14

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
  • 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, 2010 at 20:22

6 Answers 6

10

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.

4
  • 3
    The tracking point is moot: sudo -i, and your actions show up as root's, not yours Apr 30, 2010 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. Apr 30, 2010 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, 2019 at 10:49
  • The only one-user system is one that's not connected to other systems with other users (ref Battleship Galactica). If your system is connected to the internet, then it does have more than one user. Most of the time they're only running one process, ssh, but if they find a route further in... Jun 29, 2022 at 16:59
8

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.

4
  • 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, 2010 at 14:35
  • 1
    You can rename the root account, just like any other. Apr 30, 2010 at 15:07
  • @fahadsadah Some software assumes UID 0 == root. I once tried renaming root on an OpenWRT router and its web interface broke. Apr 30, 2010 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, 2010 at 22:40
5

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

2

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.

1

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

0

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.

4
  • 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. Apr 30, 2010 at 15:06
  • 1
    If you have access to the "cup holder", you don't need ssh. Apr 30, 2010 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? Apr 30, 2010 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. May 1, 2010 at 5:02

You must log in to answer this question.

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