brute force password guessing on SSH server isn't going to work?

Question

I'm running an SSH server on my personal computer. The log had many people(or bots?) repeatedly trying to log in to my server (that is before I changed the default port), which made me a little freaked out. I was worried about their dictionary attacks or brute force password guessing.

But then if you type wrong password (or wrong username), the server waits for about 2 seconds before it asks for password again. So an attacker can try one password per 2 seconds. So I concluded that these attacks aren't that great a threat (as long as your password does not consist of dictionary words.) Am I correct?

Answer 1

The suggestions in the other answers on protecting yourself further when using SSH are very sensible.

But specifically to your question, brute force attacks from a single user are unlikely to be effective except against common username/password combinations or dictionary words. A random alphanumeric 9 letter password strength is going to take around 6 million years to guess.

However, it is also possible to attack with say a large co-ordinated botnet that allows you to minimise the impact of a 2 second delay from the server for each user. One million bots (obviously not exactly likely) would reduce your cracking time down to a far more scary 6.4 years

Answer 2

SSH brute force on root passwords that are not really, really easy (e.g. "god" ;)) will probably never succeed. However there are so many people trying it, I guess there are enough people using weak enough password that it makes sense for attackers to try.

So yes, if you're using strong passwords you are probably safe, however there are several things you can do to improve your security even further (and make it possible to laugh about a 50k login attempts in your log files each day):

• use fail2ban to automatically block brute-force attackers (it creates iptables rules based on your logfiles, I think).
• disable the root account completely using "passwd -l" and use sudo instead (make sure to enable and test sudo before executing that command!)
• and even better: disable password logins via SSH altogether in sshd_config (PasswordAuthentication no) and use key files instead.

Answer 3

I install DenyHosts on any machines with internet-facing ssh servers. It automatically adds the source IPs of repeatedly failing logins to hosts.deny.

Answer 4

There is a bit more you can do with BlockSSHd.

BlockSSHD is a Perl script based on BruteForceBlocker v1.2.3 that dynamically adds IPTables rules for Linux and pf firewall rules for BSD that block SSH brute force attacks. It can also detect ProFTPd login failures.

It is quite neat and flexible.

The BlockSSHD script can unblock IP address after a period. This is enabled in the blocksshd.conf configuration file using the unblock option and with the period set using the unblock_timeout option.

The BlockSSHD script can also log the IP addresses blocked to a file and re-apply these blocked IP addresses when the script is re-started. This allows you to restore previously blocked IP addresses after a restart or when your firewall rules are flushed.

A recent digg -- 6 ways to make your SSH logins more secure.

1. Choose strong passwords
   • Disable direct root login
   • Disable password-based logins
   • Run SSH on a non-standard port
   • Ban persistent offenders (the iptables way)
   • Perl based BlockSSHd
   • Python based Fail2Ban
   • Rate-limit the connections (iptables again)

Still paranoid? User two-factor authentication,
Secure your SSH deployment with WiKID two-factor authentication