SSH Key Types and Crytography Short Notes in 2023

This is an update to my personal notes that made up my 2016 post: SSH Key Types and Cryptogpraphy: The Short Notes.

Things have changed in short 6+ years since this post. Namely DSA is long one, RSA is on well on its way out, and the two newer options in that post are now considered the minimum standard.

The too long, didn’t read version of this entire post is almost the same as what I said in 2016 - use ed25519 for your keys unless something explicitly does not support it.

OpenSSH Version References

From the notes I gathered to make the previous blog post - ed25519 was introduced in OpenSSH 6.5+

Ubuntu

OS Version OpenSSH Version
12.04 5.9
14.04 6.6
16.04 7.2
18.04 7.6
20.04 8.2
22.04 8.9

macOS

OS Version OpenSSH Version
10.12 Sierra (2016) 7.3
10.13 High Sierra (2017) 7.6
10.14 Mojave (2018) 7.9
10.15 Catalina (2019) 7.9
11.x Big Sur (2020) 8.1
12.x Monterey (2021) 8.6
13.x Ventura (2022) 9.0
14.x Sonoma (2023) 9.3

Nova / Horizon (OpenStack)

Of note ed25519 support was removed prior to Ocata, and then restored with around version 19 (Stein / Apr 2019) of nova-api.

SSH Key Types and Cryptography: The Short Notes

On nearly all current (< 3 years old) operating systems there are 4 different types of SSH key types available - both as a client’s key and the host key:

  • DSA (No longer allowed by default in OpenSSH 7.0+)
  • RSA
  • ECDSA (OpenSSH 5.7+)
  • ed25519 (OpenSSH 6.5+)

So which one to use?

In general, the best practice preference is to use ed25519 if possible, otherwise use RSA (4096 bits) due to mistrust of NIST’s curve for ECDSA. Which key is chosen/created is managed by HostKeyAlgorithms in sshd.conf, and when you create a client key by running ssh-keygen. So what about the other parts of an SSH connection, and can I use an ed25519 key anywhere?

The key types are just one portion of an SSH connection; authentication. SSH connections have three major cryptographic phases, the key exchange, the authentication, followed by the negotiated symmetric encryption used by the rest of the connection. (If you want more detail, check out Digital Ocean or Cisco’s explanations.)

Unlike the SSH key type, the ciphers and key exchange are decided on between sshd and ssh depending on their feature set and what is defined in their config files.

If you’re running OpenSSH 6.3 or newer you can see what algorithms are supported by running one of the three commands: ssh -Q [cipher|mac|kex], or read man ssh_config.

Key Exchange

A glossed over version of the key exchange, has the client and the server share some information (eg. public keys) and use the Diffie-Hellman algorithm with a decided curve to set up the cipher (symmetric key) and the MAC (message authentication code to confirm validity) to be used for the rest of the connection.

Mozilla’s recomended list of kex choices to use (specify in sshd_config) per their wiki is a great starting point. The summary being anything at least with a sha256 confirmation helps.

Encryption

The symmetric key created during the key exchange step is now used to encrypt and decrypt the rest of the connection.

Mozilla’s wiki again lists the most recommended ciphers and MACs with the new chacha20-poly1305 being the first on the list.

Key Type Reference

* - disabled by default for sshd
1 - PuTTY stable only supports dsa and rsa but the latest development snapshots support ecdsa and ed25519.

TL;DR

Unless you’re using CentOS 6 or Ubuntu 12.04, use ed25519 keys and Mozilla’s config files to limit the preferred connection ciphers.

http://www.openssh.com/legacy.html