How to prevent SSH brute force attacks

Brute force attacks on the Secure Shell (SSH) service have been used more frequently to compromise accounts and passwords. Expert John Strand explains how to defend against these brute-force threats.

Why have there been so many SSH brute-force attacks lately, and what is the best way to defend against them?

Brute force attacks on the secure shell (SSH) service have been used to compromise accounts and passwords. With this approach, an automated program often tests combinations, one at a time, of possible usernames and passphrases.

But what if an attacker doesn't care about getting access to a specific system? After all, trying 10,000 passwords against a server would most likely cause a target account to be locked out.

Instead, a malicious hacker could attempt password attacks on a large scale, using the same username and password combination on 10,000 systems. That would result in only one failed log-in attempt per server, but a much better chance of successfully compromising at least one.

Lately, attackers have been using the "low and slow" tactic, employing botnets against large numbers of servers. The technique gives them the ability to launch large-scale attacks from multiple sources.

Defending against these SSH brute-force attacks means going back to the basics of solid security practices. To start, utilize passwords and passphrases that will not be easily guessed. Doing standard "Leetspeak" -- an Internet language that substitutes letters with ASCII characters -- will not work. Attackers now use custom dictionaries that incorporate the common Leet substitutions used by sysadmins, like "@" for "a" and "3" for "e."

Also, make the root password inaccessible via a direct SSH connection by setting 'DenyUsers root' and 'PermitRootLogin no' in your sshd_config file. The majority of password attacks I've seen lately have been against the root account on systems.

More on this topic

  • See why SSH brute force attacks still going strong.
  • Learn how zombie machines were used in past SSH attacks.


This was last published in January 2009

Dig Deeper on Password management and policy