Protect SSH from brute force password-cracking attacks

In the midst of ensuring you don’t have any unnecessary services running while securing a Unix-like system from outside attacks — whether a proprietary UNIX system, a free BSD Unix system, or a Linux distribution — one of the services you’ll almost certainly come across is the SSH daemon. In most cases, this will mean OpenSSH, and you’ll want to make sure you can access a server remotely, particularly in cases where your servers are running “headless” (without monitor and keyboard).

There are automated systems out there running 24/7 that are attempting to access any computers on port 22 via brute force attacks to get past SSH password protection. If you check your /var/log/auth.log file on any system connected directly to the Internet, or perhaps connected to an open wireless access point in a coffee shop, before long you’ll likely start seeing entries at the end of the file that look something like this:

Oct 30 19:07:33 local_host sshd[6906]: error: PAM: authentication error for root from remote_host

There are a number of things you can do to cut down on the incidence of that and to reduce the likelihood of getting your system compromised by these blind attacks. For instance, a sufficiently complex password is essentially uncrackable at current technology levels. Oh, sure, any password can be cracked “eventually,” but that eventuality may take more than a century to complete with the computing resources at your fingertips today.

Another example is to simply configure SSH to listen on a port other than 22. For instance, you might assign it to listen to port 1138 (in honor of George Lucas’ 1967 movie, THX 1138 4EB). To do so, simply change the Port line in the /etc/ssh/sshd_config file to show the new port number you want to use — and be sure to use that port number when connecting from a remote system. After editing, that line in sshd_config should look something like this:

Port 1138

Port knocking can be used to provide an additional layer of security and keep the common malicious security crackers from even finding out you have an open SSH port. OpenSSH allows use of key-based authentication instead of password authentication, which can further restrict attempted attacks, as can a firewall configured to deny SSH connection attempts from all but a whitelisted set of clients.

Perhaps the most universally usable, and in many cases the most effective, means of restricting access to brute force attacks is to simply deny root access via SSH. Yes, I know — you want to be able to log in remotely and perform administrative tasks that require root access — but you also want to ensure that someone who stumbles across your machine and has the right pieces in place (such as using the correct connection port number) cannot directly gain root access to your box with a brute force, password-cracking attack.

You can still allow other accounts to access the machine via SSH, of course. With either sudo or su, you can then gain root access. Since automated attacks are even less able to guess both an unknown user account name and its password (especially if the password is sufficiently complex) — and, in fact, most never bother to try for any account other than root because of this — the security of your system from automated SSH attacks will be greatly increased by taking this simple measure. That is particularly true if you do not allow the general user accounts to use sudo or su to gain root access. You may designate a special administrative account with greatly restricted privileges on the system, but with one privilege that no other non-root accounts have: the ability to perform administrative tasks with root privileges via su or sudo.

However you choose to arrange for administrative access, once you have disallowed direct root access over SSH, it’s a very rare circumstance where you should allow remote root access at all. To disable direct root logins via SSH, edit the ssdh_config file again so that there is a PermitRootLogin line that is uncommented and set to “no”:

PermitRootLogin no

Some operating systems, such as FreeBSD, have this set as a default. Others, such as most Linux distributions, do not. Check out your particular choice of OS to determine its default PermitRootLogin setting before deciding it’s safe enough as-is.

edit: As TR user eldergabriel pointed out in a comment to this article, more information about securing the OpenSSH daemon can be found in the sshd_config manpage. Most Unix-like OSes with OpenSSH installed should have that manpage as well, and you can read it with the command man sshd_config or via whatever Unix manual interface you prefer and have available (such as the xman documentation browser).