Does disabling root login enhance security?

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.

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.

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.

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