Why You Shouldn’t Allow root Login for SSH

A few years ago, a team of students and I did some research on my university’s honeypot network and put together a little presentation about what we found. For those not in the know, a honeypot is a purposefully exposed network system intended to either divert the attention of hackers from production systems or gather information about how hackers compromise systems and the tools they use to do it. While we did gather some information about various default ports that were scanned and attacked, the main focus of the project was on SSH. By using Kippo, a specially designed SSH honeypot service, we were able to acquire information about the usernames and passwords that were used to make SSH connection attempts, and see what commands were issued after a successful login.

The main takeaway regarding what we found is just how often root is used as the username in SSH brute force attacks. In fact, just over 64% of the SSH login attempts made on our honeypot were using root. I won’t be so brazen as to claim that 64% of the entire world’s SSH login attempts use root, but it is an alarming percentage even in a research scenario. If you could invalidate 64% or even half that percentage of attacks on your SSH-enabled systems, why wouldn’t you? Just why is root the low hanging fruit when it comes to attempted SSH logins? Well, it’s guaranteed to exist, and compromising the account gives you total and complete control over the system. Of course there are other ways to restrict SSH traffic using firewalls or VPN technologies, but if you aren’t very network savvy, disabling root access for SSH is a quick and achievable goal. Sometimes I think of the username as almost a sort of password. Of course a username is usually much easier to come across, since they are typically stored in plaintext or viewable by other users on a machine. But as far as a random brute force attack on an SSH service goes, it’s just another piece of information that the attacker isn’t likely to have in advance. So, feel free to create a custom account for SSH that isn’t something you’d expect someone to guess.

On the other end of the SSH login we have the password itself. The top passwords in use were very simple, as expected. “123456” was our top password, with “password” trailing behind in second place. “qwerty”, “test”, and “root” also make an appearance shortly after. It should go without saying that you shouldn’t use a simple password. Application and hardware-specific default usernames and passwords should also be changed or disabled–hackers and hacking tools take these into account.

Creating a strong password and restricting SSH access to specific users should always be one of the first steps to hardening an SSH service. Go forth and lock down your SSH service!