SSH Public Key Authentication: Transitioning from ssh-rsa to SHA-2 signatures in OpenSSH 8.8+

Question

Signature Algorithm Deprecation
OpenSSH 8.8 and later versions have disabled the ssh-rsa signature algorithm by default. This change targets the use of SHA-1 for signatures during the authentication handshake, though the underlying RSA key pair remains valid if a more secure signature scheme is employed.

Compatibility Constraints
Systems maintaining legacy clients or servers may encounter authentication failures when the client only supports SHA-1 signatures. While the PubkeyAcceptedAlgorithms configuration can explicitly re-enable ssh-rsa to restore connectivity, this introduces known security vulnerabilities back into the handshake process.

There is a need to determine the most efficient path for transitioning existing RSA keys to rsa-sha2-256 or rsa-sha2-512 without forcing a full regeneration of all user keys across a distributed environment.

Does the server-side PubkeyAcceptedAlgorithms setting override the client's preference for SHA-2 signatures when both are available?
  What is the impact on authentication latency when the server must negotiate multiple signature schemes for a single RSA key?

Siddharth · Answer

Direct answer
The server‑side PubkeyAcceptedAlgorithms setting does not override the client’s preference; it merely filters the client’s ordered list, selecting the first algorithm the client offers that the server allows. Negotiating multiple RSA signature schemes adds only a negligible latency (well under a millisecond) because the choice is a simple set intersection after the initial key exchange.
Confirmed facts from OpenSSH behavior

The client sends its ordered list of supported signature algorithms (e.g., ssh-rsa,rsa-sha2-256,rsa-sha2-512).
  The server checks its PubkeyAcceptedAlgorithms list and picks the first algorithm from the client’s list that appears in its own list.
  If the client’s preferred algorithm (e.g., ssh-rsa) is rejected, the server proceeds to the next algorithm in the client’s list that it accepts.
  Latency impact of this extra comparison is trivial; measurements show no perceptible delay in login time.

Steps to transition existing RSA keys without regenerating them

Verify the client can offer SHA‑2 RSA signatures: run ssh -Q sig and confirm rsa-sha2-256 and/or rsa-sha2-512 appear in the output.
  If the client lacks those algorithms, upgrade OpenSSH on the client to version 8.8 or newer.
  On the server, ensure the default PubkeyAcceptedAlgorithms includes the SHA‑2 variants (they are enabled by default in OpenSSH 8.8+). No change is needed unless you previously restricted the list.
  If you must keep legacy clients that only support ssh-rsa, temporarily add it back: PubkeyAcceptedAlgorithms +ssh-rsa in /etc/ssh/sshd_config, then reload sshd. Note this re‑introduces the SHA‑1 signature vulnerability.
  Test authentication with verbose output: ssh -vvv user@host true and look for lines like offering public key: … followed by sent … signature algorithm to confirm a SHA‑2 algorithm was chosen.

Missing diagnostic detail
To give a definitive recommendation, we need to know the client’s signature algorithm list. Please provide the output of ssh -Q sig from the affected client system.

SSH Public Key Authentication: Transitioning from ssh-rsa to SHA-2 signatures in OpenSSH 8.8+

Signature Algorithm Deprecation

Compatibility Constraints

1 answer

Direct answer

Confirmed facts from OpenSSH behavior

Steps to transition existing RSA keys without regenerating them

Missing diagnostic detail

Your perspective belongs here.

0 question comments