[
https://issues.apache.org/jira/browse/SSHD-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17721061#comment-17721061
]
Thomas Wolf commented on SSHD-1325:
-----------------------------------
I don't understand. If the {{ClientBuilder}} is used, the default signature
order will be the one from {{BaseBuilder.DEFAULT_SIGNATURE_PREFERENCE}}. See
{{ClientBuilder.setUpDefaultSignatureFactories()}}. These default settings _do_
work.
We did notice in Eclipse before that if you include ssh-rsa in the KEX
proposal, it should come _after_ rsa-sha2-512, rsa-sha2-256. Otherwise some SSH
servers may wrongly decide on the wrong signature. But your issue is not about
KEX...
{{BuiltinSignatures.VALUES}} is a {{Set}}. Therefore, _no_ particular order is
guaranteed, so code using it should not assume any particular order. Likewise,
the order of the enumeration constants in {{BuiltinSignatures}} it unrelated to
any order that might make sense for {{PubkeyAcceptedAlgorithms}}.
> 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-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
