I'm currently working on hardening my servers against hacking- amongst other things, i'm getting a load of attempts to log on as root over ssh. While i've implemented fail2ban, i'm wondering, why root logons would be allowed by default to start with? Even with non sudo based distros, i can always log on as a normal user and switch - so i'm wondering is there any clear advantage to allowing root logons on ssh, or it just something no one bothers to change?
There are some backup systems that need root on the remote system to actually perform a backup. It is not uncommon to see things setup with key-based authentication to perform maintenance tasks on remote systems.
I do strongly wish the default would be changed from
PermitRootLogin yes
to at leastPermitRootLogin without-password
, this would allow key-based authentication only. Remote password authentication to the root account is almost never needed.It is becoming more common on systems (like Ubuntu) for the system to be setup with a root account with a disabled password. There isn't much risk in the default setup since there is no way to directly authenticated to an account with a disabled password.
Also consider that a brute force attempt to remotely login to root via ssh has a very low chance of being successful if you have a root account with a sufficiently complex password. Disabling the root account does provide an extra layer of security, but it may not be needed if you have a strong password. If you combine a strong password with a reactive tools like denyhosts and fail2ban there is usually almost no risk that an attempt to brute force the root password will work.
It is always a good practice to harden the system after the install is done based on the risk and the requirement for your network. A system that not critical and has no user data doesn't really need the same level of hardening as the system that stores medical or banking records.
I'm not sure, but I would assume that they wanted to make sure that people doing foreign installs could login. The first login might need to be root since there are no other users yet.
However, you must make sure to disable the login as root option in the sshd config after you have created your user and given him sudo permissions.
I also recommend that you change the SSH port to something other than 22. While it doesn't make your machine more secure - it does stop all those wasteful/annoying requests.
Consider preventing root logins as an extra protection. Some years ago bruteforce was at its peak, nowdays, they tend to look for vulnerabilities via what they can see by the deamons (apache, pureftpd, ...). Preventing root logins become an excellent idea if tomorrow an exploit is found with SSHD. While SSHD is mature and secure, you never know. Lately the exploits have been more toward priviledge escalation with the kernel or using a third party app with the kernel so preventing root logins wouldn't have changed a thing.
Debian based distro already made the switch while RedHat based distro's suggest it (if you read their best practices docs)
Well, because root is a valid user and sshd does it job allowing it. On OpenBSD (same guys from OpenSSH), for example, you are not asked to create a user during installation, so you need to use root to access your box.
Some desktop-based distributions force you to create additional users, but for servers you actually don't need one.
Also, these arguments that sudo or su are more secure than logging in as root is a big myth. On Ubuntu, for example, the user can run ANY command using sudo by default, so any attacker who get in can also run ANY command as root. Pretty useless from a security perspective.
It's pretty much distro specific. Some allow it, some don't.
If I was managing a distro, I would configure the system to be as hardened as possible at install. It's better to forget to enable some feature than it is to forget to disable some faeture.