Home > Support > HOWTO List > Preventing Brute Force SSH Attacks

By just having a listening server on the Internet, you may get dozens or even hundreds of brute force login attempts each day. Most of these attempts come from automated scripts running on other compromised machines. If you are tired of reading logs filled with such entries, or just want to better protect your server, there are a number of things that you can to do. The following solutions work either by block the attempts completely, or making them unsuccessful.

Combining several of the below methods allows you to do "defence in depth", that is to use a layered approach which is helps in case one solution is somehow not working.

Limit login attempts

If you need to permit logins from arbitrary addresses, consider using a program like DenyHosts or Fail2ban. They watch for failed logins and add the IP addresses of attackers to /etc/hosts.deny and/or update firewall rules to null route them.

Fail2ban is preinstalled on all our new server setups, and configured out of the box to protect ssh.

DenyHosts can also be configured to synchronize with a global database so you can proactively deny hosts that other users have blacklisted.  Keep in mind that mistyping your password when you try to log in will then probably lock you out of your VPS.

Use strong passwords

Brute force attempts will try common passwords like words (or combinations of words) in a dictionary, names, and common passwords. Strong passwords generally use a combination of upper and lower-case characters, numbers, and non-alphanumeric characters. A good command line tool for generating random passwords is 'pwgen', which is available for install on all our distrbutions.

Even better, disable password logins over ssh. Instead, install your public key on the server and use it to log in. If all of your users use public keys, you can set PasswordAuthentication to 'no'. To disable password authentication just for root, use 'PermitRootLogin without-password'.

Change the ssh port

Run sshd on a non-standard port. Since most automated attacks only attempt to connect on port 22, this can be an effective way to hide from automated attackers. To configure this, just change the Port line in /etc/ssh/sshd_config and restart ssh.

Port 1022

Define users that can login in the ssh service

Use the AllowUsers directive in the ssh configuration to only allow certain users or IP's. In /etc/ssh/sshd_config, you can specify a list of allowed users like this:

AllowUsers bob john root@ root@

This will allow users 'bob' and 'john' to log in from anywhere, and root is only allowed to log in from those two IP addresses.

Limit access using iptables rules

If you will always be connecting to your server from the same IP address, you can firewall off port 22 to everything EXCEPT your own IP address.

iptables -A INPUT -p tcp -d 0/0 -s YOUR.IP.GOES.HERE --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -d 0/0 --dport 22 -j DROP

Then run 'iptables-save'

If you setup IP tables this way then it may will also obviously prevent you from connecting to your server except from that one source IP.

You can whitelist more IPs easily enough, if you use this approach we recommend adding the IPs used by our support team adding those used by our support team as well.

Another method is to use 'hashlimit' in 'iptables':

iptables -I INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m hashlimit --hashlimit 1/min
--hashlimit-mode srcip --hashlimit-name ssh -j ACCEPT 

This rule limits one connection to the SSH port from one IP address per minute. Note the order of the options is important, to help avoid bottlenecking the hashlimit module.

For more information, 'man iptables' and 'iptables -m hashlimit --help'.

Port knocking

Use port knocking to completely hide the port your SSH server is listening too. This will of course make it pretty complicated for you to log in.

Cant get in?

If you manage to lock yourself out of a VPS, you can always log in using the root password via our Console feature in our control panel. Or our team are happy to help restore access.

Further reading

This page is a suplement to "Securing your server". We also have a bunch of good security related guides and articles