12 October 2014

I’ve collected a huge amount of bookmarks that discuss SSH tips and best practices. Let’s consolidate them here. First the best practices in no particular order:

  • Protect Private Keys with a Passphrase - If you don’t enter a passphrase when generating your private key it will be stored in plain text.
  • Use ssh-agent to Reduce Typing - Use ssh-agent to reduce the number of times you need to type in your private key’s passphrase.
  • Generate and Store Private Keys on a Smart Card - Look for cards that support OpenPGP or use a commercial product like Crypto Stick.
  • Use Protocol v2 Only - Only allow protocol version 2. Version is is known to be insecure.
  • Disable Password Authentication - Only use keys if possible.
  • Create a Banner - Show your legal disclaimers at each login.
  • Use Two-Factor Authentication - Google Authenticator has a PAM module to enable TFA for SSH. Note it does NOT need to hit outside servers to function.
  • Consider gpg-agent for Private Keys - GPG uses stronger encryption and more passes.
  • Lockdown Using Directives in authorized_keys - Lots of options in here, look for the AUTHORIZED_KEYS FILE FORMAT section of the man page.
  • Install Keys via Configuration Management Software - Why push your public keys over and over, let the CM software handle it. Makes it easy to revoke access, too.
  • Think About Backups - Are unencrypted private keys being backed up? If so, who has access to them?
  • HashKnownHosts - Have SSH save known hosts as hashes rather than plain-text hostnames so the attacker won’t know which system(s) to jump to next.
  • Store Host Keys in DNS - Not a best practice but a neat trick, look at the VerifyHostKeyDNS option.
  • Only Use the Original EC2 Keypairs as a Backup - Don’t use the keypairs that are generated when an EC2 instance is spun up for day to day access.

And now the tips, tricks, and a couple hardening guides - also in no particular order: