Possible Duplicate:
Is it worth the effort to block failed login attempts
Is it normal to get hundreds of break-in attempts per day?

I'm managing a number of completely different root servers in different data centers and I notice a quite high number of failed SSH login attemts on most of them. Here is a snapshot from the past three days:

SSHD login attempts graph

There is no regular pattern, but generally I log a few hundred attempts a day. To me this seems like botnets randonly trying to enter into foreign servers. I use rather safe passwords, but still: should I be concerned or do something about this?

Best would probably be to change the SSH port, but that is not possible in all cases.

Anyway, is this normal?

NB: The PublicKey logins are as expected.

marked as duplicate by Bart De Vos, dunxd, Iain, mailq, Ward Nov 3 '11 at 1:30

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • Yes this is normal. – OliverS Nov 2 '11 at 15:49
  • Yes it's normal. Check the location of the IPs connecting. I've found a good majority, 75% or more, come from asian netblocks. I ended up setting up my iptables to block all SSH access from all known asian netblocks and that removed a majority of my logged attempts. – Alan Barber Nov 2 '11 at 18:25

Things you can do:

  1. It is possible to set up iptables rules to block ssh attacks, theses rules will allow at most 3 connections per minute from any host, and will block the host for another minute if this rate is exceeded.

    iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force " iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

  2. Block via syslogs

    2.1 sshdfilter: uses iptables for blocking (i.e. it dynamically adds custom firewall rules to block a specific attacker).

    2.2 Fail2Ban: is a Python script which adds custom firewall rules to block an attacker.

    2.3 DenyHosts : does not use firewall rules to block an attack. Rather, it writes blocking rules to /etc/hosts.deny.

  3. Use Port Knocking (like knockd)

  4. The best solution, use RSA AUTHENTICATION:

    If you don't use passwords but only RSA keys for authentication, a brute force search for a valid password will obviously be useless.

Note: You can combine somes of theses tips, but simple Rsa auth + port knocking is a rock-solid solution.


You should be concerned and take steps to harden your servers.

Following up on cop1152's answer:

  1. You could change the port. However if you have clients that regularly use ssh, and expect the default port, this is not an option.
  2. You could use a package such as fail2ban (http://www.fail2ban.org/) to temporarily ban IPs that make several unsuccessful login attempts in a short amount of time.
  3. If you know the IPs from which your clients log in, you can use fail2ban to block all IPs except those from known IPs (AKA whitelisting: http://www.fail2ban.org/wiki/index.php/Whitelist).

A great way to stop these attempts is to set up Port knocking.
Some tools to do this are knockd (C), fwknop (C), KnockKnock (Python) and KnockKnockServer (Java), to name a few.

Port knocking kan keep your SSH port closed to the outside until a "secret knock", or Single Packet Authorization is received.

After your server gets the secret knock, the firewall allows new SSH connections for a couple of seconds, allowing you to establish a connection.

port knocking image

It can cause a bit of an inconvenience but you'll no longer have failed login attempts from botnets.

Image credit: cipherdyne.org


Change the port, but also have rule that bans IP's that attempt to login and fail numerous times. Additionally, consider only allowing logging in from certain IP's and do not allow root logins. Make sure the user has to elevate to admin to do anything.

And you can do better than "rather safe passwords" probably. A Google search will show you some fairly easy ways to make your SSH connections more secure.

No offense, but if you are charged with managing these servers, you should know these things already. I havent mentioned any specific packages for download, but they are easy to find.

  • Yes, sure, they aren't new to me. I was merely wondering if so many attempts are typical for a server on a public IP. – Udo G Nov 2 '11 at 14:09
  • My bad..didnt mean to pounce, no disrespect intended. The very first server that I was charged with, which wasnt that long ago, I had the same exact concerns. I believe I posted a similar question here... – cop1152 Nov 2 '11 at 14:14
  • Why the -1? The advice is sound. Sure I didnt spoon feed it, no links, but really? -1? – cop1152 Nov 2 '11 at 14:35
  • No clue. I didn't -1 this. Thanks anyway for your answer. – Udo G Nov 2 '11 at 14:44
  • Usually I leave a comment if I am going to down vote something. Some dont. Anyway, some good answers here, definitely better than mine, very specific. I love this site because I always learn something new. – cop1152 Nov 2 '11 at 14:48

Running on the default ssh port and on a public IP and probably open to connections from everyone. Yes these things are regular. If you use safe and strong passwords, you might be safe to some extent but again you never know.

A few things to do would be:

  1. use public key based authentication and if possible disable password based authentication.
  2. Disable root login.
  3. change ssh port to some random, if changing it across all the servers, have some mechanism to remember them.
  4. use some automated blocking of such intruding IPs using fail2ban or other similar packages.
  5. Deploy a RAS server (OpenVPN) and only allow ssh off this RAS server to those servers. Isn't always doable but does reduce your chances of getting probed.
  • Great suggestions! I've got only 80, 443, and 21 open to non-vpn'd user's and it works very well. Disabling root login and password authentication is a no brainer if port 22 is exposed! I had success with fail2ban on previous servers where 22 was exposed but much prefer the vpn isolation – iainlbc Nov 2 '11 at 18:47
  • Yes, in my deployments I generally do the same, to all administrative services like ssh and monitoring over web (I run them on other non standard ports) and allow them only from the VPN. – Gaumire Nov 3 '11 at 3:16

A few things you could/should do:

  • Change the port
  • Tigthen iptables (max connections/min, selected IP's,...)
  • Disable root ssh-login
  • Disable plaintext passwords
  • Use key authentication
  • Use Port Knocking (maybe a bit over the top)

Whenever you have a server that is accessible to the internet, you will come across this. Most of them are just scripts trying a few combo's. I put this command in my MOTD to keep track of it.

echo -ne "Total failed attempts: $(grep 'Failed password' /var/log/auth.log* | wc -l) failed attempts"

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