[jira] [Comment Edited] (SSHD-1104) Fix Client Side Support for RFC 8332 rsa-sha2-256, rsa-sha2-512 public key authentication

["Lyor Goldstein (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SSHD-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237496#comment-17237496 ] 

Lyor Goldstein edited comment on SSHD-1104 at 11/23/20, 4:53 PM:
-----------------------------------------------------------------

{quote}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.
{quote}
You are right - however the behavior you mentioned requires more complex coding. The current "fix" provides a good enough workaround for the time being. I will open a continuation issue for the behavior that you describe.
{quote}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.
{quote}
You are correct as to the current implementation going over the keys instead of signatures - this is how the code always worked. I can see the logic for doing this the other way around, but this is a more complex code change (I will open a separate issue for it).


was (Author: lgoldstein):
{quote}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.
{quote}
You are right - however the behavior you mentioned requires more complex coding. The current "fix" provide a good enough workaround for the time being. I will open a continuation issue for the behavior that you describe.
{quote}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.
{quote}
You are correct as to the current implementation going over the keys instead of signatures - this is how the code always worked. I can see the logic for doing this the other way around, but this is a more complex code change (I will open a separate issue for it).

> 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: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org