Preface

Many system administrators switch SSH daemon settings, so that it listens on another port than default 22. Why do they do it, does it make any sense? This post describes some ways to make your SSH server properly set up.

Security through obscurity

Using another port than default 22 is an approach called security through obscurity. It seems to many people like changing port from default will protect them from automated scans / attacks. But in case of this action, we're only implementing "obscurity", not "security". Here are the reasons why it does not improve security at all:

• SSH server advertises itself with specific string sent after recieving connection. Therefore, it's very easy to figure out on which port SSH deamon runs, if it's not port 22
• If someone has the data required to connect to your server (like SSH key or password), it will take just seconds to find out where your server runs
• Hiding from script kiddies doesn't offer much for you. I guess you're not using default or easy to guess passwords, right? If you do, then you're in real trouble, anyway
• If a 0-day vulnerability would be found in SSHD, you're still vulnerable - just a little bit more effort is required to find out how

Good practices for SSH server

Instead of poorly hiding your service on another port number, make sure that you're using SSH in proper way. Some good practices include, but are not limited, to:

• Don't allow logging in to your server as root - use sudo instead. There is a setting in /etc/ssh/sshd_config:

  PermitRootLogin no
  

• Make sure that each user has seperate account, don't use shared accounts - you don't see who is logging in to your machines. Even if you have to deploy your application (common case for Capistrano), it's possible to do it without shared account
• Don't allow password authentication - using SSH keys is much more secure. SSH keys should also always be protected with a password, so that if they leak (stolen laptop?), they will stay secure. Sample configuration entries:

  RSAAuthentication yes
  PubkeyAuthentication yes
  AuthorizedKeysFile      .ssh/authorized_keys
  HostbasedAuthentication no
  IgnoreRhosts yes
  PasswordAuthentication no
  ChallengeResponseAuthentication no
  KerberosAuthentication no
  

• For each SSH key, use clear identifier. Each SSH key has an identifier, that is automatically generated - and can be easily changed. The default name is often meaningless (like [email protected]). Use personalized email address or firstname/lastname. You don't need to re-generate your SSH key after changing its ID.

  ssh-rsa AAAAB...... [email protected]
  

• Manage your accounts and ssh keys. If you are doing this manually, then you can easily forget about some servers, when someone leaves your company. Chef, Puppet, SaltStack, Ansible can easily automate account creation and deletion for you. Or, even better, use a centralized system for user privilege management, like ActiveDirectory or even simple LDAP server. This will make your life much easier and gives your good overview about your users and their privileges
• Protect yourself from brute-force attacks - by rate-limiting failed ssh logins. It's pretty easy on current Linux distributions with fail2ban. It's available as package to install and relatively easy to configure. It puts IP addresses which fail too many times in a row in seperate firewall table, rejecting them to access your servers for some (limited) time.
• Cut access to SSH from Internet - but only if you can do it. If you can require VPN connection before connecting to SSH - do that. But make sure that you wouldn't cut access for yourself if something goes wrong. Imagine the situation that you have simple VPN gateway server - and it goes down. Would you have alternative way to connect to your servers? If not, then disabling SSH access from internet could do more harm than good for you. But if you have a pair of redundant routers, a failover setup or VPN provided by datacenter or cloud, it's good idea to use it.
• Use remote logging - it does not really mean any SSH configuration, but it's a related topic, worth mentioning here. Make sure that you forward your logs (including information about SSH logins and sudo usage) to another machine (with something like rsyslogd or logstash). If someone mis-behaves and has root access to your machine, he can delete all traces of his activity (by wiping log entries or whole logs). You should forward your logs in real time to another hosts, so that even in case of losing local logs (this can also happen due to hardware malfunction, not only bad users), you will still have the remote copy.