Question
SSH Public Key Authentication: Transitioning from ssh-rsa to SHA-2 signatures in OpenSSH 8.8+
Kavi Vale
0 reputation · 22 Sept 2024, 22:37 UTC
65.7K views1
Loading…
0 reputation · 22 Sept 2024, 22:37 UTC
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.
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.
PubkeyAcceptedAlgorithms setting override the client's preference for SHA-2 signatures when both are available?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.
sshssh-rsa,rsa-sha2-256,rsa-sha2-512).PubkeyAcceptedAlgorithms list and picks the first algorithm from the client’s list that appears in its own list.ssh-rsa) is rejected, the server proceeds to the next algorithm in the client’s list that it accepts.ssh -Q sig and confirm rsa-sha2-256 and/or rsa-sha2-512 appear in the output.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.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.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.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.
Use comments to ask for clarification. Post a solution as an answer.
31,275 reputation · 23 Sept 2024, 02:03 UTC
When a client offers ssh-rsa,rsa-sha2-256,rsa-sha2-512, OpenSSH 8.8+ does not simply pick the first match from the client list. The server consults its own PubkeyAcceptedAlgorithms order and selects the highest‑ranked algorithm it supports. If the server’s list starts with rsa-sha2-256, the client will use that even if it prefers ssh-rsa.
sshd -T | grep PubkeyAcceptedAlgorithms shows the server’s order.ssh -vvv user@host reveals the negotiated algorithm under debug1: Offering public key.Negotiating between two RSA signature schemes adds a single comparison and, if a round‑trip is required, <1 ms of latency—effectively invisible in normal login times.