Repository navigation
Conversation
'ecdsa-sha2-nistp521' and 'rsa-sha2-512' were joined into one invalid name, so neither algorithm was advertised to clients.
RFC 4252 section 7 requires USERAUTH_PK_OK to carry the public key algorithm name from the request. For rsa-sha2-256/rsa-sha2-512 requests the server sent 'ssh-rsa' instead, which OpenSSH 10.6 rejects: server replied to PK_OK with signature type ssh-rsa not in PubkeyAcceptedAlgorithms ctx.key.algo is still 'ssh-rsa' for RSA keys, so existing authentication handlers are unaffected.
OpenSSH 10.0 removed DSA, and the +ssh-dss options made every integration test fail there. Detect support with `ssh -Q key`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi there
Thanks for ssh2! After updating my arch I could no longer log in with my RSA key to a server we run on top of ssh2:
ssh -vvalso showed something odd in the server'sserver-sig-algs, two names glued together:My ed25519 key still works, so it seems to be RSA keys only. I bet more people will hit this as distros move to OpenSSH 10 (which I think happened to me). Claude helped me track it down, details below. Split into 3 commits in case you only want some of it.
Note; the change is done by Opus 5.5 on max with claude, codex, vibe and antigravity as reviewers.
From Claude, what is in this PR:
lib/protocol/handlers.misc.jsmapsrsa-sha2-256/rsa-sha2-512tossh-rsa, andPKAuthContext.accept()inlib/server.jssent that mapped name inUSERAUTH_PK_OK. RFC 4252 section 7 requires the algorithm name from the request, and OpenSSH 10.6 now enforces it. The requested name is carried separately as_requestedKeyAlgo, soctx.key.algois still'ssh-rsa'and existing authentication handlers are unaffected. Clients that requestssh-rsagetssh-rsaback as before.server-sig-algs.sendExtInfo()inlib/protocol/Protocol.jsjoinedecdsa-sha2-nistp521andrsa-sha2-512into one invalid name, so neither was advertised. One side effect: OpenSSH clients will now pickrsa-sha2-512against ssh2 servers. The server already verifies that throughhashAlgo.+ssh-dssoptions made every case intest/test-integration-openssh.jsexit with 255. DSA support is now detected withssh -Q key(also covers 9.x builds without DSA), and the two DSA cases are skipped when it is missing. With OpenSSH 10.6 this test fails without the fix and passes with it.test/test-userauth.js. They wrapclient._protocol._handlersto checkUSERAUTH_PK_OKandserver-sig-algsas received by the client, since the client ignores the PK_OK algorithm otherwise. Cases:rsa-sha2-256,rsa-sha2-512,ssh-rsaand ECDSA. Each fix makes them fail when reverted on its own.npm testandnpm run lintpass on Node 26.13 with OpenSSH 10.6.