Jan Philipp created SSHD-1325:
---------------------------------
Summary: 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
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
