SSH Key Best Practices

Ensure Separation

Ensure SSH Keys Are Associated With a Single Services

Tie SSH keys back to an individual services, rather than just a generic key that is associated with multiple services github / acquia /aws etc . This will provide an effective SSH audit trail and more direct oversight.

Use a separate key per client you SSH from

So don’t copy the private key from your laptop to another laptop for use in parallel. Each client system should have only one key, so in case a key leaks, you know which client system was compromised. If you stop using your old laptop and start using a new one it is naturally another case and then you can copy the key.

Comments

Adding comments to keys can allow you to organize your keys more easily. The comments are stored in end of the public key file and can be viewed in clear text. For example:

cat ~/.ssh/{keyservice}_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDG..........qiaWxRUdk0UKU0c5ZqQYHRCw== username@hostname

Choose different SSH algorithm

Once a key pair is generated, its algorithm cannot be changed. So you need to be careful about the algorithm. Some of the options are as below:

• RSA – Default and most popular algorithm. It is based on the difficulty of factoring large numbers. A key size of at least 4096 bits is recommended for RSA. RSA is getting old and significant advances are being made in factoring. Choosing a different algorithm is advisable where possible.
• DSA – An old US government Digital Signature Algorithm. It is based on the difficulty of computing discrete logarithms. A key size of 1024 would normally be used with it. DSA in its original form is no longer recommended.
• ECDSA – A new Digital Signature Algorithm standardized by the US government, using elliptic curves. This is the recommended algorithm for current applications/service if supported. Only three key sizes are supported: 256, 384, and 521 (sic!) bits. Most SSH clients now support this algorithm.
• ED25519 – This is one of the new algorithms added in OpenSSH. Support for it in clients is not yet universal. You need to check the documentation of the SSH clients and servers, if they support this algorithm.

Key Generation

NOTE: Only use RSA if it is the only option for the service offers, follow "Choose different SSH algorithm"

The algorithm is selected using the -t option and key size using the -b option.

If you do not want the ssh-keygen to prompt you for the filename, you can supply it using -f option.

To add a comment to the public key file when generating the key add to the key generation command -C "username@hostname". The following commands illustrate:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/github_rsa -C "username@hostname"

ssh-keygen -t dsa -f ~/.ssh/github_dsa -C "username@hostname"

ssh-keygen -t ecdsa -b 521 -f ~/.ssh/github_rsa -C "username@hostname"

ssh-keygen -t ed25519 -f ~/.ssh/github_ed -C "username@hostname"

Stay vigilant

If running ssh remote.example.com yields some error messages, don’t ignore them! SSH has an opportunistic key model, which is convenient, but it also means that if you are confronted with warnings that the connection might be eavesdropped you should really take note and not proceed.