The OpenSSH suite of tools, developed by the OpenBSD Project, includes popular programs that serve many uses. This popularity combined with ssh availability as both server and client on just about every OS makes it no wonder that ssh has been the target of common attacks; and as a result, many tools have been created to help cope with some of these common brute-force attempts.
Common sense, however, can turn these attacks into nothing more than an annoyance and wasted space in logfiles. For starters, explicitly setting who is able to log in will help defeat 99 percent of these brute-force attacks, regardless of how secure your system really is.
To begin with, never allow root to log in via ssh unless you absolutely must, and in that event, always use ssh keys. Never allow root to log in with a password. To do this, edit /etc/ssh/sshd_config (on some systems it is simply /etc/sshd_config) and add:
PermitRootLogin without-password
This will allow root logins, but only with an appropriate ssh key, the public counterpart of which must be set in /root/.ssh/authorised_keys.
Second, explicitly define which users are able to log in. Again, editing sshd_config, add:
AllowUsers root
AllowUsers joe
This will only allow the users root and joe to log in via ssh. Note that as soon as you enable one AllowUsers option, no users can login unless they are listed. In other words, despite the PermitRootLogin setting, if you do not set "AllowUsers root" and have "AllowUsers joe" in your configuration, root cannot log in even with a proper key. Keep an eye on this list over time and make sure that users who no longer require access to the system are removed from it.
You can further tighten the security here by specifying not only a username that can be permitted, but the originating host they can log in from by specifying a user@host pattern.
In other words, if you specify joe@10.0.5.1 then access to the user account joe will only be granted to connections originating from the IP address 10.0.5.1. You can specify various patterns here, such as joe@10.0.* to allow access from any system in the 10.0.0.0 network range.
The ssh_config(5) manpage has more details on allowable patterns that can be used.
Finally, if you do not require PAM-based authentication, set:
UsePAM no
This is the default and should only be enabled if you need PAM-based authentication that sshd cannot obtain on its own. For example, this would be required if you had a user account that authenticated via LDAP (and thus pam_ldap); without enabling UsePAM, that user could never log in. However, once you enable UsePAM, other options do not work as you may expect. For instance, "PermitRootLogin without-password" will not work properly and if a valid ssh key is not provided, it will fall back to a PAM-based authentication prompt for the root user's password.
At this point, by merely using the AllowUsers keyword, most brute-force attempts are mitigated because the attacker needs not only to guess the correct password, but also the correct account. Any attempts to log in as other users not in the allowed-user list will result in failed login attempts, even if the correct password is provided.
