HARDENING OPENSSH

OpenSSH’s daemon (server) configuration file is stored in /etc/ssh/sshd_config, so you’ll need to edit that (as root) to make changes to the setup.
The first thing to do is find this line:

PermitRootLogin yes

Change yes to no here to disable direct root logins via SSH. This immediately adds an extra layer of security, as crackers will have to log in with a regular user account and password first, and then know the root password as well. (Warning: make sure you have a regular user account on the system first, because if you only have a root account, you can lock yourself out by changing this!)

Next, add a line like this to the configuration file:

AllowUsers mike graham ben

This restricts which users can log in via SSH; if you have many accounts on the machine but only one or two will log in, this is worth doing.

Next, change this line:

Port 22

22 is the standard SSH port, so it’s a good idea to change this to something else (and make sure that your router or firewall is also aware of the change if you’ll be logging in from outside your network). A random number like 1234 is fine here – it adds a bit of “security through obscurity”. When you log in with the ssh command now, you’ll need to add -p 1234 to the end of the command.

Triple lock

Now, these three changes are useful enough on their own, but together they add a major layer of protection against automated cracking scripts and bots. These are programs that attempt to break into your machine by repeatedly trying username and password combinations, many times a second, until they get access. (If you have a net-facing machine with OpenSSH that has been online for a while, look in
/var/log/auth.log and you’ll probably see many login attempts from IP addresses around the world.)

The default OpenSSH configuration means that these bots don’t have to do much work: they know that the root account is available, and they know to try on port 22. By disabling root access and switching to a different port, the bots have to do a lot more guesswork, trying random ports and usernames.
If you have a strong password, this makes it very difficult for a bot to gain access.

Once you’ve made your changes to /etc/ssh/sshd_config, you’ll need to restart the OpenSSH daemon:

service ssh restart

One enormously useful add-on for OpenSS is Fail2ban. This is a program that monitors unsuccessful login attempts; if a certain IP address fails to log in too many times, that IP is automatically blacklisted. This again adds more work for crackers and bots, as they can’t keep trying to log in from the same IP address and need to switch periodically.
On Debian it’s a simple

apt-get install fail2ban 

away, and it starts up automatically.
By default it automatically blocks IPs (using the system’s iptables command) for 600 seconds if they have six failed login attempts. You may want to raise the duration to something much longer, and also allow IPs a few more attempts – you don’t want to make a few typos when entering your password and accidentally ban yourself!

Fail2ban’s main configuration file is /etc/fail2ban/jail.conf. However, it’s a bad idea to edit that directly (as your changes could be overwritten by system updates), so copy it to /etc/fail2ban/jail.local and edit that file instead. The bantime and maxretry options towards the top control the default settings we mentioned before, and you can also exempt certain IPs from being banned in the ignoreip line.
But hang on – maxretry here at the top has a value of three, yet we mentioned earlier that there must be six failed login attempts for Fail2ban to take effect!
This is because there’s a special “[ssh]” section further down that overrides the default settings. You’ll see that Fail2ban can be used with other services than SSH too. Once you’ve made you changes, restart the program like so:

service fail2ban restart

Passwordless authentication

While good passwords are hard to crack, you can make it almost impossible for nasty types to log in by disabling password authentication, and using public/private key pairs instead. On the machine(s) you use to log in, enter ssh-keygen to generate the keys, then accept the defaults for the file locations and the blank password. (If you suspect someone else might get access to the machine you’re using, you can set a password for the key.)
Now enter ssh-copy-id followed by the hostname or IP address of the server; your public key will be transferred over to that server. Try logging in and you should see that you don’t need to specify a password any more.
If it all works, edit /etc/ssh/sshd_config, change the PasswordAuthentication line to no, and restart OpenSSH.
(And never give away your private key – it’s ~/.ssh/id_rsa!)