I’ve decided to collate what I’ve picked-up on this topic as much of the advice I’ve found on the net is rather fragmented. Following these instructions is no substitute for reading the documentation with your SSH server and should be followed at your own risk – this is very much a brief round-up and not a detailed HOWTO. Anyway, having any services publicly available to the internet is a security risk and no amount of preparation can provide 100% certainty against compromise.

1. Is your version of SSH up to date? Do you have a system for ensuring that it is kept up to date? None of the tips in this post will be of any use if your server has any known vulnerabilities (or any largely unknown ones for that matter, although the only way to effectively protect against these is to give up and unplug the network cable The same should apply for all the other services you make available to the internet as having a tightly locked-down SSH daemon won’t be much use if your mail and web servers are full of holes. Make sure you have a reasonable understanding of what it takes to secure your machine – see the related reading section below for some starting points.
2. Work out how sshd is started and with what command line options. For example, are you sure you know what configuration file the server is using? The default is /etc/ssh/sshd_config, but it is possible to change this using the -f switch on the command line used to start the server. Check your startup scripts to be sure.
3. Audit the user accounts on your system. This is the sort of more general security measure that you should be taking anyway, but it’s worth mentioning here. Some common account names are targeted by the automated brute-force password cracker scripts out there, so be careful of accounts with names like admin, user, guest, test, etc. Where possible also make sure that the system accounts required by some services have no passwords set and have something sensible set as their shells like /bin/false.
4. Think carefully about from where you need to allow access to the server: does every machine on the net really need to be able to connect to it? You can use the /etc/hosts.allow and /etc/hosts.deny files to control access (see man hosts_access), as well as setting up iptables rules only permit access from trusted IPs or ranges of IPs, for example (assuming you drop incoming packets by default):

   iptables -A INPUT -s $TRUSTED_IP -p tcp --dport 22 -j ACCEPT

5. Carefully read the relevant manual pages, particularly sshd and sshd_config. Then read your /etc/ssh/sshd_config file – do not assume that your vendor or distribution has not altered any of the default variables. Some variables to pay particular attention to include:
   • Protocol – set this to 2 so as to not allow connections to fall back on protocol 1.
   • Make sure that PermitRootLogin in set to no.
   • Set PasswordAuthentiction to no whenever possible.
   • Set PubkeyAuthentication to yes (default) and set up keypairs for users (see man ssh-keygen and man ssh-agent).
   • Set PermitEmptyPasswords to no (default).
   • Set StrictModes to yes (default).
   • Set UsePrivilageSeparation to yes (default).

   Hopefully most of these variables will be in the states described. Note that some linux distributions use PAM to authenticate users connecting to the SSH server. This is beyond the scope of this article – see the UsePAM directive in the sshd_config manpage and the Linux-PAM website for more information on this.

6. You can use the AllowUsers and AllowGroups directives and their DenyUsers and DenyGroups counterparts to limit access to trusted users or deny access to system accounts or untrusted users. Particularly useful if you need to allow password-based authentication.
7. If you need to allow blanket access to the server from the internet, investigate methods for throttling large numbers of simultaneous incoming connections. Two worth investigating are:
   • The built-in MaxStartups directive in the sshd_config file. This sets the number of unauthenticated connections that are allowed at any one time before the server starts ignoring new connection attempts, and can be useful if you find your server is being targeted by brute force attackers making lots and lots of simultaneous or near-simultaneous connections. Read the sshd_config man page for more information on this.
   • Use the recent extension to iptables to track incoming connections and drop any from the same IP within a given number of seconds. This is very effective aganist the brute-force password crackers:

     iptables -A INPUT -p tcp -m state --state NEW --dport 22 \
      -m recent --update --seconds 15 -j DROP 
     
     iptables -A INPUT -p tcp -m state --state NEW --dport 22 \
      -m recent --set -j ACCEPT

8. Some people may recommend moving the server to an unusual port by setting the Port directive in sshd_config, others may suggest implementing port knocking to control access. Although these solutions may afford you some additional security, the former is just a form of security through obscurity, although it’s probably quite effective against the automated scanners. The latter method is not without detractors, but can also be useful. Anyway, neither should be used as a substitute for other security measures, so I’ll say no more about them here.

This article has been re-written from a stub that really just referenced the article that inspired it, Securing access to your server checklist. Feedback is very welcome.

Related reading

• The OpenSSH hompage
• The netfilter/iptables homepage
• The Linux Security HOWTO
• The Linux-PAM homepage