[
https://issues.apache.org/jira/browse/SSHD-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738281#comment-17738281
]
Thomas Wolf commented on SSHD-1331:
-----------------------------------
I read this statement from the RFC a bit differently. The first algorithm in
the client's list that the server also supports is {{{}ssh-rsa{}}}, so that is
the algorithm that should be used.
The fix in an Apache MINA sshd client is to simply ensure that rsa-sha2-512
comes before rsa-sha2-256 comes before ssh-rsa. Which is the default setup.
Compare also SSHD-1325.
> SSH Algorithm negotiation
> --------------------------
>
> Key: SSHD-1331
> URL: https://issues.apache.org/jira/browse/SSHD-1331
> Project: MINA SSHD
> Issue Type: Question
> Affects Versions: 2.9.2
> Reporter: Pavel Pohner
> Priority: Major
>
> Hello,
> I'm facing a weird issue with SSH signature algorithm negotiation:
> Signature algorithms for RSA are sorted like this in my implementation:
>
> {code:java}
> List<BuiltinSignatures> RSA_SIGNATURES = List.of(
> BuiltinSignatures.rsa,
> BuiltinSignatures.rsaSHA512_cert,
> BuiltinSignatures.rsaSHA256_cert,
> BuiltinSignatures.rsaSHA512,
> BuiltinSignatures.rsaSHA256 {code}
> when establishing connection with server that offers following lists of
> algorithms, the connection is established without any issue:
> {code:java}
> ssh-rsa
> rsa-sha2-512
> rsa-sha2-256 {code}
> but, when server with list of algorithms in following order is encountered:
> {code:java}
> rsa-sha2-512
> rsa-sha2-256
> ssh-rsa {code}
> the connection fails with following exception: *KeyExchange signature
> verification failed for key type=ssh-rsa*
> Based on SSH RFC my current understanding is, that in the second scenario,
> algorithm guessing happens, where my implementation (client), guesses the
> *ssh-rsa* algorithm, meanwhile the server guesses the {*}rsa-sha2-512{*}, in
> that case the guess is not successful and there's defined algorithm that must
> be followed (basically, client iterating over the common list of algorithms
> until finding the correct match) -
> [https://datatracker.ietf.org/doc/html/rfc4253#section-7.1]
> This seems to not be the case though as the exception says that the signature
> verification failed for *ssh-rsa,* I would expect the implementation to
> iterate to the *rsa-sha2-512* and match the server's guessed algorithm.
> How is this handled in Mina SSHD implementation? Is this something I can
> override/handle in my own implementation? Can someone point me in the right
> direction please?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
