Major Hayden over at Racker Hacker has a post on locking down SSH, and making it a little more secure, including some references to ssh keys, and how to set them up. A good read, and here are a few more ideas too…
Use a non-standard port
I know it was already mentioned, but there are other utilities too, that make this a little more interesting, and a lot more convenient. Take for example sslh. It runs as a listener on 443, the standard https port, and redirects to the appropriate daemon depending on what the protocol is you connected with. Why’s that good? It means when you’re on an untrusted network, where they limit which ports you can connect to, chances are https is one of the available ones.
Blocking root
This should be top of the list to do when setting up an SSH server, if it isn’t already done so by default. This is a flag in the sshd_config file (usually located in /etc/ssh/sshd_config):
PermitRootLogin false
Disabling passwords, and interactive keyboards
Whilst it was mention to use keys, it doesn’t mention how to disable the passwords. There are two settings to watch in the sshd_config for this. The first is pretty obvious:
PasswordAuthentication no
This disables using passwords, but if you try connecting without an SSH client using ssh keys, you may find it still prompts for a password, this is because of an option called keyboard-interactive. This can be disabled using the following option:
ChallengeResponseAuthentication no
Firewalls
Again, already mentioned, but this is a general security thing, you should make sure the policy for your firewall is drop:
iptables --policy INPUT DROP
This should be applied after you’ve added your rules so you can get to it. Of course, there is no harm in being extra cautious and adding the drop rule as well. Checkout programs like shorewall, they make setting up rules a breeze and rarely can you go wrong with them.
fail2ban
If you really cannot lock down your ssh daemon to a particular block of IP addresses, then fail2ban, and its kin, are your best friend. Whilst they won’t protect you from being hacked, they’ll help reduce the attacks, and brute force attempts by watching logs, and enforcing firewall rules to kill off those pesky attempts.
Combining these hints with the original article, and the many others on securing SSH (and general server security), and you can get a good way towards ensuring server security. Always remember though, security is an ever changing field, what might be secure today, may be an open hole tomorrow. Security still remains as strong as the weakest link, firewall rules may block your access, but a messed up script running in apache can give the user all the access they may need.