[
https://issues.apache.org/jira/browse/SSHD-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237096#comment-17237096
]
Justin Tay commented on SSHD-1104:
----------------------------------
Thanks for working on this. I've tried the codes and have the following
comments.
I noticed that for rsa keys it will only attempt one signature algorithm, ie.
if rsa-sha2-512, rsa-sha2-256, ssh-rsa is defined. It will always pick the
first one. I somewhat expected it to try the signature algorithms in sequence,
ie first rsa-sha2-512 then rsa-sha2-256 and then ssh-rsa.
I think the main source of my confusion is that I actually expected the
signature algorithms to be attempted in order of preference, ie iterate the
signature algorithms and then find and iterate the eligible keys for that
algorithm. Instead it seems to be iterating through the keys in the sequence it
was added. So if for instance the signatures were defined as
ecdsa-sha2-nistp521, rsa-sha2-512, ecdsa-sha2-nistp384, rsa-sha2-256 and I then
added the rsa key and then the ecdsa 521 key. I would expect
ecdsa-sha2-nistp521 to be attempted first, followed by rsa-sha2-512 and then
ecdsa-sha2-nistp384 and then rsa-sha2-256 regardless of the order in which the
keys were added.
I actually intend to have a client KexExtensionHandler that will apply the
intersection of the client and server-sig-algs so that the client doesn't try
sig algorithms that the server didn't declare support for so I had expected the
client to iterate the session signature factories and perform auth in that
sequence provided the eligible keys were available.
> Fix Client Side Support for RFC 8332 rsa-sha2-256, rsa-sha2-512 public key
> authentication
> -----------------------------------------------------------------------------------------
>
> Key: SSHD-1104
> URL: https://issues.apache.org/jira/browse/SSHD-1104
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 2.5.1
> Reporter: Justin Tay
> Assignee: Lyor Goldstein
> Priority: Minor
>
> The readme on the client side support for RFC 8332 is misleading. It implies
> that the client side just requires specific initialization so the impression
> is that either setting the kex extension handler or signature factories
> should get the client to be able to use public key authentication using
> rsa-sha2-256 or rsa-sha2-512.
> However after removing the ssh-rsa signature factory and encountering an
> error I noticed that in UserAuthPublicKey and KeyPairIdentity the signature
> algo (P. K. Alg. Name) is always set to be the key type (P. K. Format) which
> will always be ssh-rsa ie. algo = KeyUtils.getKeyType(getPublicKey()) so P.
> K. Alg. Name always equals P. K. Format and doesn't make calls to
> KeyUtils.getAllEquivalentKeyTypes or check the configured signature factories.
> Getting this to work required overriding UserAuthPublicKey,
> UserAuthPublicKeyFactory and awkward handling of the
> KeyPairIdentity/PublicKeyIdentity for signing which was more than what I
> expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
