[jira] [Commented] (SSHD-1325) Not useful sorting of signature algrithms?
[
https://issues.apache.org/jira/browse/SSHD-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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) 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
[jira] [Commented] (SSHD-1325) Not useful sorting of signature algrithms?
[
https://issues.apache.org/jira/browse/SSHD-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721084#comment-17721084
]
Jan Philipp commented on SSHD-1325:
---
Thomas, thank you for details. Indeed back in 2021 we had switched to
BuiltinSignatures.VALUES because DEFAULT_SIGNATURE_PREFERENCE missed some. I
missed that, so I thought the current situation would be only-way of going for
defining the signature algorithms. My fault, sorry for the confusion. :( In a
poor attempt at justification at my side :), I would appreciate that the
JavaDocs would be more helpful what the actual defaults could/would be, at
least as a hint of useful constants in BaseBuilder.
Regarding the reference to the set. Technically you are right, the set is not a
guarantee for the order. I had actually only suspected an implicit sorting due
to the JDK (enums are "static", and and I'm probably right about that).
Nevertheless, we should not do that, no question.
So: If no signatures are defined, it works. It annoys me that I didn't have
that simple test case with me at all. If using BuiltinSignatures.VALUES, it
fails (always) because of the ordering.
End of story is: This is not an issue, we can close this. I will stick with the
BaseBuilder.DEFAULT_SIGNATURE_PREFERENCE but extended with the missing
(deprecated) items we need in this specific situation. These ensures we include
the recommended order by Mina itself.
> 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) 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
[jira] [Commented] (SSHD-1325) Not useful sorting of signature algrithms?
[
https://issues.apache.org/jira/browse/SSHD-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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) 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
