I get a lot of SSH connection attempt from different IP on my server (with different username). 1 to 5 per seconds. It look like a brute force attack. What can I do to prevent that? Block the IP? change the SSH port? Something else?


migrated from stackoverflow.com Feb 8 '10 at 19:47

This question came from our site for professional and enthusiast programmers.

11 Answers 11


The DenyHosts package is one that is freely available and will block "bots" from attempting repeated attacks to your ssh port.


Great software for blocking them.

Note: it's also included in many distros by default.

  • You can install fail2ban. It serve exactly this purpose, blocking brute force attempts. It works with other servers like http/ftp/etc too.
  • You can block the ip manually but this is more a temporary solution.
  • You can change the SSH port as you suggest. Unless it is a requirement for you to run it on the standard port, this is a very good idea. Most attackers won't take time to find out if you have a public ssh server running and on what port, except maybe if the attack is targeted specifically at you.
  • 1
    fail2ban is useless because the bots connect once per botnet IP. – chris Feb 9 '10 at 13:31
  • it bans IPs every day on my ssh server – f4. Feb 17 '10 at 23:21

Changing the ssh port solves it quite well. Never had any problems (it is just too costy for brute forcers to scan the range once there are so many machines with the defaut port).

  • 1
    Requiring a key-file also adds a lot to security, on the price of sacrificing some of your mobility (no access-from-any-netcafe, but that is not too safe anyway). – ron Feb 8 '10 at 18:45
  • I've done this too, but some bots eventually find the port. I wouldn't rely on this alone. It certainly wouldnt stop a brute force attack. A quick scan with nmap and I'd have your SSH port in a heartbeat. :) – Mech Software Feb 8 '10 at 19:00

Don't change the port (permanently) it's pointless against any sophisticated attack and only creates obstruction. Good security is in good policy, not obscurity. If you can consider limiting access to a set of known IPs, if you can't consider denyhosts, as mentioned above. You should also talk to your ISP about this, maybe there is an attack on a segment o their network and they are unaware.

  • changing the SSH port is the single most useful thing you can do to secure your SSH server. – Justin Feb 9 '10 at 12:44
  • 1
    no, but it's a single most useful thing you can do to fool yourself that you did improve security. – monomyth Feb 10 '10 at 19:10

You might find http://www.snowman.net/projects/ipt_recent/ useful for this - you can do something like this:-

iptables -A INPUT -m recent --rcheck
--seconds 60 -j DROP iptables -A INPUT -i eth0 -d -m recent --set -j DROP

So I did a combination of :

  • It is generally recommended to add an outline of the linked information to your post itself. e.g., what functionality of IPTables did you use, what are the relevant parameters in your ssh config etc. – moooeeeep Mar 6 '17 at 10:46

If you are setting lots of failures from different IP addresses your server is being targeted by a distributed brute force attack. some key points:

  • if you were running ssh on a port other than 22 this attack would have never targeted you
  • running something like denyhosts generally will not help at all because attacks like these are tuned to have a low enough number of attempts per IP - the last attack like this I saw used a few thousand IPs

So, steps to securing your SSH server:

  1. Change the port. Every automated attack only scans port 22. If you are running ssh on port 22 and you start seeing login failures, it just means that you got picked up in a port 22 sweep at some point. If you are running ssh on port 12501 and you start seeing login failures, you have much bigger problems. If all else fails, not having port 22 open prevents you from being an easy target.
  2. Block access to the ssh port from everywhere but your network. If you don't have a static IP, then setup knockd or a VPN to allow you to connect from anywhere. Setting up knockd is considerably simpler than setting up a VPN.

Requiring key based authentication doesn't really secure the ssh server, it secures authentication. If you only rely on key based authentication to secure the server, you open yourself up to any potential exploits against openssh. If a 0day exploit was released against openssh and you are running ssh on port 22 and relying on keys to "secure" your server, it will be hacked within hours.

A much better practice is to not even allow people to connect to the ssh server in the first place.


+1 for changing the port.

If you always have a static IP, block all access from everything but that IP.

It's difficult to block IPs if either you have a dynamic IP, or your brute force attack is coming from multiple IPs.

If the IPs are common, i.e. it's always a range of 10 IP addresses doing the attack, find out which ISP owns them and submit an abuse report with log entries.


another +1 for changing ports - at a bare minimum. Otherwise, set up a VPN and firewall everything except the VPN connection. It's the best of both worlds in my opinion.


If it is a single (or only a few) remote IPs trying to log in, you can install a host route for the IP(s), with a gateway of (the loopback interface). That way, they cannot establish a TCP session, but you run the risk of running out of kernel resources (at 1-5 attempts per second, it should be OK, though).


This has been answered already but just to add something that I don't see mentioned...

You can disable root login.

If you were to do this in Centos you would would change the following in /etc/ssh/sshd_config:

PermitRootLogin no

Most brute force attacks are against the root user.

Make sure that other system users don't have generic names i.e. 'admin' or 'public' or your name, i.e. 'dave'. The attacker would have to brute force the user name and the password together, it just isn't going to happen.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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