How to Add Protective Measures Against SSH Attacks on Linux Systems

Earlier this week, I noted that ssh brute force attacks are on the rise. These attacks attempt to guess SSH passwords by repeatedly accessing your server. Often these attacks can disrupt SSH services. As I noted yesterday, you can use IPtables to rate-limit or throttle ssh connections. Today, I want to expand on that protection by adding some more security to SSH directly.

These ssh hardening measures can be applied to most servers without ill effects. There are certainly more security measures but their application may be limited. I will discuss those in a future post.

Strong Passwords
Nearly every month, we clean up a system due to poor password security. Most commonly the issue is with end-user’s email accounts but if these accounts also have shell access, then poor passwords can be guessed easily by a brute force attack. Password crackers are very efficient. They do not use a random attack but sophisticated heuristics and dictionaries to identify passwords.

I use PCTool’s secure password generator. I recommend using 8–12 character passwords with at least one symbol and one number.

Disable SSH Protocol 1
SSH has two protocols 1 and 2. Protocol 1 has a number of known flaws and should no longer be used. You can disable Protocol 1 by editing /etc/ssh/sshd_config

#Protocol 2,1
Protocol 2

Restrict Root Login
You can also set SSH to not permit direct login to root. There are two options: “no” disables all direct root logins, “without-password” disables root login by using a password. I often use the later to maintain the convenience of logging in as root. “Without-password” may sound insecure but it actually forces root to us an SSH key.

#PermitRootLogin yes
PermitRootLogin without-password

Reduce Grace Time
By default ssh will wait up to 2 minutes to allow a user to authenticate. If you are on a very slow connection, this may be necessary but typically the long wait period results in holding unauthenticated connections open. You can reduce this to 30 second, which should be plenty time for someone to log in.

#LoginGraceTime 2m
LoginGraceTime 30

Even More Security
When I get a chance, I will provide some tips for providing even more SSH security, such as getting rid of passwords completely and limiting which users can use SSH.