Everybody on the Internet advises to disable root login via SSH as it is a bad practice and a security hole in the system, but nobody explains why it is so.
What is so dangerous in enabling root login (especially with disabled password login)?
And what is the difference between X symbol username and Y symbol password or root username and X+Y symbol password from security point of view in case password authentication is allowed?
There are a lot of bots out there which try to log in to your computer over SSH. These bots work the following way.
They execute something like ssh root@$IP and then they try standard passwords like "root" or "password123".
They do this as long as they can, until they find the right password.
On a world wide accessible server you can see a lot of log entries in your log files. I can go up to 20 per minute or more.
When the attackers have luck (or enough time), and find a password, they would have root access and that would mean you are in trouble.
But when you disallow root to log in over SSH, the bot needs first to guess a user name and then the matching password.
So lets say the list of plausible passwords has N entries and the list of plausible users is M entries large. The bot has a set of N*M entries to test, so this makes it a little bit harder for the bot compared to the root case where it is only a set of size N.
Some people will say that this additional M isn't a real gain in security and I agree that it is only a small security enhancement. But I think of this more as these little padlocks which are in itself not secure, but they hinder a lot of people from easy access. This of course is only valid if your machine has no other standard user names, like tor or apache.
The better reason to not allow root is that root can do a lot more damage on the machine than a standard user can do. So, if by dumb luck they find your password, the whole system is lost while with a standard user account you only could manipulate the files of that user(which is still very bad).
In the comments it was mentioned that a normal user could have the right to use sudo and if this user's password would be guessed the system is totally lost too.
In summary I would say that it doesn't matter which user's password an attacker gets. When they guess one password you can't trust the system anymore. An attacker could use the rights of that user to execute commands with sudo, the attacker could also exploit a weakness in your system and gain root privileges. If an attacker had access to your system you can't trust it anymore.
The thing to remember here is that every user in your system that is allowed to log in via SSH is an additional weakness. By disabling root you remove one obvious weakness.
The reason to disable passwords is really simple.
The whole idea of trying passwords only works when the passwords are guessable. So when a user has the password "pw123" your system becomes insecure. Another problem with passwords chosen by people is that their passwords are never truly random because that would then be hard to remember.
Also it is the case that users tend to reuse their passwords, using it to log into Facebook or their Gmail accounts and for your server. So when a hacker gets this user's Facebook account password he could get into your server. The user could easily lose it through phishing or the Facebook server might get hacked.
But when you use a certificate to log in, the user doesn't choose his password. The certificate is based on a random string which is very long from 1024 Bits up to 4096 Bits (~ 128 - 512 character password). Additionally this certificate is only there to log into your server and isn't used with any outside services.
The comment from @Philip Couling which should have been an answer:
There's an administrative reason for disabling root. On commercial servers you always want to control access by person. root is never a person. Even if you allow some users to have root access, you should force them to login via their own user and then su - or sudo -i so that their actual login can be recorded. This makes revoking all access to an individual much simpler so that even if they have the root password they can't do anything with it. – Philip Couling
I would also add that it allows the team to enforce the principle of least privilege, with a proper sudo configuration (but writing one sounds easier then it is). This enables the team to distribute uncritical better, without giving away the key to the castle.
http://bsdly.blogspot.de/2013/10/the-hail-mary-cloud-and-lessons-learned.html
This article comes from the comments and I wanted to give it a bit more prominent position, since it goes a little bit deeper into the matter of botnets that try to log in via SSH, how they do it, how the log files look like and what one can do to stop them. It's been written by Peter Hansteen.
N*M > N. Since most *nix hosts have a root user, if you allow root to log in directly from a remote host, the size of the test matrix is the number of passwords to try; disallowing direct root logins, the number of possible combinations multiply with the number of usernames you want to test (and there's still no guarantee that you'll be testing valid usernames!).
These could be some of the reasons why direct root login should not be allowed.
But this is just the TIP of the iceberg. You need to configure other restrictions and configurations like:
You're right that root username and X+Y symbol password is cryptographically at least as secure as an X symbol username + Y symbol password. In fact it is even more secure, cause people's names are easy to guess (bots may just try john, mike, bill, etc... and btw: that's what many of them do instead of trying root). And you're especially out of luck if it's a targeted attack, cause if someone wants to break a company's server it wouldn't be a problem to find out the name (nick) of the sysadmin.
And as soon as the attacker has access to the account the sysadmin uses for ssh logins (and then uses su or sudo to do his tasks) he can infect that user's session with a program which will send the attacker root password when the sysadmin types that the next time.
It's any type of root logins which are (or should be) considered bad practices from security point of view. The "normal" user login -> su/sudo chain adds an audit trail. In plain english: it makes it possible to find out who did what.
A special case may be the one, where only one person has root access. In that case using the additional "normal" user won't add much value (at least I never could see that value). But anyway - you're supposed to have a simple user on the system anyway (for non-administrative tasks, running wget, etc ;-) ).
What is so dangerous in enabling root login ( especially with disabled password login )?
The attacker (bot/botnet/hacker) only need to guess the password and has complete control over your system, if you are open to the internet. Also, none of the systems accounts (www-data, proxy, etc.) should be able to login via SSH, for the same reasons.
If you disabled password login (using public key, for example), take into account that whoever gets hold to the private key gets complete control over your system. See why using public key with a user is better below.
And what is the difference between X symbol username and Y symbol password or root username and X+Y symbol password from security point of view in case password authentication is allowed?
The extra username can add a layer of security since: a) attacker should know both pair, username and password; b) in case attacker breach your system it wouldn't have immediate access to a privileged account adding a bit of nuance for the attacker.
In this case public key is also a plus, since:
It's not exactly bad as long as you take safety precautions. As an example you could install CSF (Configure Server Firewall) and set it the number of allowed failure attempts, so if someone tried ,let's say over 5 failure attempts?, then they are automatically blocked. So the entire first part of the best answerer won't be a problem at all. This happened to me many times, and luckily all the introducers were blocked permanently. I guess for a server it isn't a big problem if you are the only person who manages the server, but of course if there are a lot of system admins, or if you are working in an organization, then obviously don't use root. Also for a desktop PC, I guess using another account is better as there is a security risk since you use a lot of software, but in a server, you don't go for random software that you don't trust, you make sure to keep them as low as much as possible. So the conclusion is, No it's not really harmful if you know how to manage a server properly.
su -orsudo -iso that their actual login can be recorded. This makes revoking all access to an individual much simpler so that even if they have the root password they can't do anything with it.