Armor SSH and Block Brute Force Attacks

OpenSSH is a battle-tested app plenty of admins rely on, but there are plenty of configuration choices you might be missing.

 By Carla Schroder
Page 1 of 2
Print Article

OpenSSH is a good stout application; it's battle-tested and reliable. You can lock it down even further with a few simple tweaks. Best of all, these cause little or no inconvenience after they are set up.

The first thing you should do is create some access controls that allow only authorized users to login. There are several options in /etc/ssh/sshd_configfor this:

PermitRootLogin no
Protocol 2
AllowUsers  fred ethel lucy ricky@desilu.net
AllowGroups  admins

Use the ListenAddress directive when you have more than one network interface on your machine, such as border routers or firewalls, or multi-homed servers connected to several different subnets. Suppose your firewall has a WAN port and two LAN ports. You can have sshdlisten only on the LAN ports, or on just one of them, and not listen on the WAN port at all. You can do the same thing with a multi-homed server- the easy way to control SSH access on selected subnets is with the ListenAddress directive. You can check this with netstat:

router2:~# netstat -untap
tcp        0      0*               LISTEN     539/sshd
tcp        0      0*               LISTEN     539/sshd
tcp        0      0      ESTABLISHED754/0

That is on an Internet-facing router with three LAN interfaces and one WAN interface. It confirms that SSH access is allowed only on two of the LAN interfaces, and the third line shows an active connection.

Disallowing root logins over untrusted networks is a wise practice. It's a bit of a pain having to log in as an unprivileged user, and then using su or sudowhen you need root privileges, but it's a lot less pain than cleaning up after a successful intrusion. You definitely don't want to expose the root user to brute-force password attacks. Even better is disallowing password logins entirely, which we'll get to in a moment.

"Protocol 2" means do not allow connections from clients using the SSH1 protocol. SSH1 is old mold and not safe; anyone still using it is seriously behind the times.

AllowUsers is obvious. Restricting them to specific hosts locks them down further, so ricky cannot log in from just anywhere, like public terminals which doubtless are infested with keystroke loggers and other unpleasant pests.

AllowGroups can save you some work by creating a system group and stuffing your authorized ssh users into it.

Saving Your Logfiles

You're probably familiar with the trick of telling sshdto listen on a different port:

Port 8000

Then you must specify the port when you connect:

$ ssh carla@remotehost -p 8000

This won't fool a determined attacker, who will sniff out the listening port quickly enough. But it does foil 99% of the stupid automated brute-force attacks that infest the internet, and your logfiles will be a lot cleaner.

Password-less Logins

Using public-key logins is a great way to protect your system login and 100% foil brute-force attacks. You can use the same key to log into multiple machines, a different key for every machine, or mix-n-match.

The first step is to collect host keys from all the computers you're going to connect to remotely. This is what happens the first time you log in to a remote ssh server, and it says

The authenticity of host 'fooserv (' can't be established. RSA key fingerprint is 11:22:4a:1f:dd:ac:d1:88:2d:aa:65:00:a5:ee:b9:38. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'fooserv,' (RSA) to the list of known hosts.
This article was originally published on Jun 4, 2007
Get the Latest Scoop with Networking Update Newsletter