[2022-06-23]
Recently, the Internet has been shouting all around the place (and further) that ssh-rsa
SSH keys are deprecated and must not be used anylonger.
And I’ve been tearing my hair off explaining to lost souls they are not, that RSA key pairs are atill perfectly safe and usable (provided you’re not using a 20-year old key with a 512-bit length).
The important thing to note about RSA key pairs and (Open)SSH is that the ssh-rsa
(and rsa-sha2-*
) identifiers cover two entirely different (almost orthogonal) aspects:
the key type, used when creating the key (with ssh-keygen
); in the case at hand a (raw) RSA key pair
the signature algorithm negotiated when using the key (as part of the SSH client-server handshake) - customizable in ssh_config
(client), sshd_config
(server) or authorized_keys
(server) configurations - which historically was SHA1 only but nowadays also (and recommendly) SHA2 (256 or 512); that algorithm is not part of the (raw) RSA key pair itself (mark my words: “that [signature] algorithm is not part of the (raw) RSA key pair itself”)
As standardized in the (original) RFC4253 and updated in the (SHA2-related) RFC8332.
Now, much misunderstandings seem to have spawned from OpenSSH deprecating the use of the SHA1 (ssh-rsa
) signature algorithm - as of OpenSSH 8.2 - used during the SSH handshake (and not part of the RSA key pair itself), with many people jumping to the RSA (ssh-rsa
) key type being deprecated and EVIL.
This was further amplified by people relying on tooling and SSH clients which - as of (late) 2021 - were still not able to use SHA2 signature algorithm - despite its introduction in 2018 (RFC8332) - and attempting to connect to modern SSH servers that enforced SHA2-only handshakes (along ssh-rsa
key type).
The most notorious example being Go(Lang) native SSH client/server (library), which SHA2 support was added in November 2021 (…) and upon which many cloud native tools rely (e.g. HashiCorp Packer, Terraform, etc.).
So, to cut it short:
ssh-rsa
is still a perfectly valid (and safe) key type
you do not need to generate new RSA key pair to use SHA2 during the SSH client-server handshake, given the signature algorith is not part of the (raw) RSA key material (PS: if still relying on a 20-year old key with a 512-bit length, it might be time to consider a longer bit length, though)
SSH clients and servers will negotiate the signature algorithm to use during the handshake and modern ones will default to SHA2 even if ssh-rsa
is used in your SSH configurations (ssh_config
, sshd_config
or authorized_keys
)
outdated clients or servers may only support - or default to - SHA1 signature algorithm during the handshake, reason security-conscious people may prefer to force SHA2 using rsa-sha2-256
or rsa-sha2-512
stanza in their SSH configuration
of course, outdated clients (supporting only SHA1) connecting to modern servers (enforcing SHA2) will fail to connect; don’t blame ssh-rsa
, blame the client!
sigh…