Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 9 down vote accepted

There any clear advantage to allowing root logons on ssh

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 least PermitRootLogin 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.

share|improve this answer

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.

share|improve this answer
I really disagree with changing from standard ports. Use packet filtering. – Warner Mar 25 '10 at 3:34
Really? What is bad about it? I just started doing it because I saw respected admins doing it... – Xeoncross Mar 25 '10 at 4:01
It's something people adopted from running co-located servers with no filtering or network segregation. – Warner Mar 25 '10 at 4:58
@Warner but, I don't understand, changing from standard ports wouldn't be a quite simple way for most people to just fend off most attempts? – Camilo Martin Jul 9 '12 at 18:42

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)

share|improve this answer

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.

share|improve this answer
on the other hand, a attacker would need to guess both the username and the password- as opposed to just brute forcing the password. I'd also note sudo is restricted to people in the sudoers file - so its just the first user in most cases – Journeyman Geek Mar 25 '10 at 13:36

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.

share|improve this answer
Hardening system as much as possible becomes challenging if you are also trying to get your system used on the desktop by lots of end users. You need to compromise and harden the system just enough to protect users in the default case but allow advanced users to modify the system to fit their needs. – Zoredache Mar 25 '10 at 6:32

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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