[ https://issues.apache.org/jira/browse/SSHD-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17721491#comment-17721491 ]
Thomas Wolf commented on SSHD-1325: ----------------------------------- I quite agree that documentation could be improved. A simple flag for including the deprecated algorithms in the default setup might perhaps also help, or in fact always include them in the client-side setup, but never in the server-side setup. Clients typically want to be compatible also with older servers, so they want to include old algorithms. In fact, in JGit I had done exactly that when Apache MINA sshd deprecated dsa and rsa. See [https://git.eclipse.org/r/plugins/gitiles/jgit/jgit/+/refs/heads/master/org.eclipse.jgit.ssh.apache/src/org/eclipse/jgit/transport/sshd/SshdSessionFactory.java#627] . > 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