[jira] [Closed] (SSHD-1325) Not useful sorting of signature algrithms?

["Jan Philipp (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SSHD-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Philipp closed SSHD-1325.
-----------------------------
    Resolution: Invalid

> Not useful sorting of signature algrithms?
> ------------------------------------------
>
>                 Key: SSHD-1325
>                 URL: https://issues.apache.org/jira/browse/SSHD-1325
>             Project: MINA SSHD
>          Issue Type: Bug
>    Affects Versions: 2.9.2
>            Reporter: Jan Philipp
>            Priority: Major
>
> We found the current (default) settings may result into authentication problems when using the MINA SSHD client against "modern" remote SSH servers.
> {{org.apache.sshd.common.SshException: No more authentication methods available}}
> A RSA key will not be accepted by the server anymore. It depends on the OS (well, actually, on the crypto (default) settings). The same key and the same destination host *will* work when using the "native" OpenSSH client.
>  
> The actual culprit is the deprecation of RSA+SHA1 issue which already have some issue stories here at Jira also :)  Basically the usage of RSA keys is still fine, but the usage of SHA1 will be disallowed and this is enforced by modern OS. Said that, OL9 (EL9) deprecates SHA1 via crypto-policies.
>  
> The technical order when using {{BuiltinSignatures.VALUES}} is {{{}dsa{}}}, {{{}dsa_cert{}}}, {{{}rsa{}}}, {{{}rsa_cert{}}}, {{{}rsaSHA256{}}}, etc. When using an RSA key, the type is {{ssh-rsa}} and this is _always_ {{rsa}} and this is always {{{}RSA with SHA1{}}}. 
> Meanwhile, as far as I understand this correctly, OpenSSH clients may treat {{ssh-rsa}} as RSA with SHA256; the MINA SSHD client does not support this. That may the reason why the native OpenSSH client actually works.
> As a workaround, the list of supported signature algorithms can be tweaked (because the order of appearance is used for matching). If the match finder is trying {{rsaSHA256}} for {{ssh-rsa}} at first, it will never try the non-working {{rsa}} again.
> In order of not missing future value additions, I have used this code to meet this.
>  
> {code:java}
> // push back these options to the end
> final var deprecated = List.of(
>         BuiltinSignatures.dsa,
>         BuiltinSignatures.dsa_cert,
>         BuiltinSignatures.rsa,
>         BuiltinSignatures.rsa_cert
> );
> client.setSignatureFactories(
>         Stream.concat(
>                         BuiltinSignatures.VALUES.stream()
>                                 .filter(not(deprecated::contains)),
>                         deprecated.stream()
>                 )
>                 .map(s -> (NamedFactory<Signature>) s)
>                 .toList()
> );
> {code}
> Although this seems to work, I want to raise this here for discussion:
>  # Is this workaround actually correct or have I missed something which could be an issue in the future?
>  # I can see a growing issue of "mina does not work" because if seems to break with default settings. IMHO either the order (like the workaround) must be changed or the matcher should look for other matches also (which he does not atm).
> I also find some issues on this topic (NIFI-10586 is a different project, but seems to be the same problem), and related here SSHD-1105 and SSHD-1141. This does not seem to be solved in 2.9. If I have missed something, please correct me.
> A full demo is available in my repo-demo at [https://github.com/knalli/poc-mina-sshd-ssh-rsa-issue]. The demo uses Testcontainers for spinning up the samples, so you need Docker or something compatible.
> The demo contains 2x2 tests against a container with Oracle Linux 8 respective 9 configured with password respective with a RSA public key. OL8 works fine, and password also. Only the "modern" OL9 with an RSA public key fails. I've added an additiona test `run2` with the enabled workaround.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org