Armor SSH and Block Brute Force Attacks - Page 2

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 2 of 2   |  Back to Page 1
Print Article

Now you must generate your personal identity key pair:

$ ssh-keygen -t rsa
Generating public/private rsa key pair...

You may choose to protect it with a passphrase, or you may not. There are two schools of thought on this. One is that a passphrase-less private key is plenty secure, because you are a very careful person who does not lose her keys. My own view is human-user keys need passphrases, especially mobile human users or human users who work around other humans, who snoop and pry and make trouble.

chmod 400 your private key, to protect it from accidental overwrites. It is stored in your ~/.ssh/authorized_keys2directory. If this does not exist, create it and make it mode 0700.

Now you must distribute your public keys to your ~/.ssh/authorized_keys2 files on all of your remote hosts. Use the ssh-copy-idscript to do this:

carla@localmachine:~$ ssh-copy-id -i  id_rsa.pub carla@remotehost.net

After you have done this and tested that everything works, go into sshd_configon the machines you are logging into and disable password logins:

PasswordAuthentication no

You can take this a step further and disable local logins, so that a person who is sitting at the physical machine cannot log in:

# passwd -l carla

passwd -uenables the login.

Just keep in mind the old saying: she who has physical access to the machine owns it. This won't stop a person with a bootable Linux CD or USB key getting in, unless you disable those too. Or just walking away with the whole works, if they want it badly enough.

If you create multiple personal identity keys you'll have to give each one a different name. Use something descriptive so you know what they are:

$ ssh-keygen -t rsa -f  id_httpserver1

Then you'll need to specify the key when you log in:

$ ssh -i  id_httpserver1 carla@remoteserver

Preserving Port 22 With Fail2ban

An alternative to putting sshd on a different port is to run the excellent program Fail2ban. Fail2ban is for all services, not just OpenSSH. Fail2ban is a brute-force blocker that writes rules to /etc/hosts.deny, or it will write iptablesrules, to block offending IP addresses.

The default installation automatically protects SSH. You don't have to lift a finger. If you look in /etc/fail2ban/jail.conf, you'll see this:


enabled = true
port	= ssh
filter	= sshd
logpath  = /var/log/auth.log
maxretry = 6

You'll also see entries for other servers such as Apache, and various SMTP and FTP servers. These are not enabled; to activate any of these change enabled = "false" to "true."

You may wish to tweak the maxfailures = setting; the default is 6 failed attempts before Fail2ban writes a block. bantime = defaults to 600 seconds, or ten minutes; after ten minutes the ban is lifted. -1 is permanent.

For insurance, you could use the ignoreip =option to make sure you don't block your own self with fat-fingered typing. This takes a space-separated list of IP addresses like this:

ignoreip =


This article was originally published on Jun 4, 2007
Get the Latest Scoop with Networking Update Newsletter