[jira] [Closed] (SSHD-1325) Not useful sorting of signature algrithms?
[
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) 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&focusedCommentId=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
[jira] [Created] (SSHD-1325) Not useful sorting of signature algrithms?
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) 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-1293) ExplicitPortForwardingTracker does not unbind auto-allocated one
[
https://issues.apache.org/jira/browse/SSHD-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607158#comment-17607158
]
Jan Philipp commented on SSHD-1293:
---
For reference [https://github.com/apache/mina-sshd/pull/241] and merged right
now.
> ExplicitPortForwardingTracker does not unbind auto-allocated one
>
>
> Key: SSHD-1293
> URL: https://issues.apache.org/jira/browse/SSHD-1293
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Jan Philipp
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> I have noticed that the de-allocation (unbind of a forwarding) initiated by
> {{org.apache.sshd.client.session.forward.ExplicitPortForwardingTracker}} in
> the {{close()}} method will not no close the actual forwarding. Said that,
> this leaves the connection and a file handler open.
> The actual main reason is that it uses
> \{{manager.stopLocalPortForwarding(this.getLocalAddress());}} which means it
> stops the tunnel identified the "local address" which is the same as provided
> by the user. If the user is using a local address with port {{0}} (which
> seems legit since the docs state this explicitly), the local address will be
> still something like {{0.0.0.0:0}} or maybe {{{}127.0.0.1:0{}}}, but only the
> "bound address" contains the actual dynamic auto-allocated port.
> If the user uses an explicit port, this would work.
> As a workaround, I have added after {{tracker.close()}} an explicit
> {{session.stopLocalPortForwarding(tracker.getBoundAddress())}}. I don't know
> if this would your final solution or this would be an issue in
> \{{DefaultForwarder#stopLocalPortForwarding}}.
>
> I'm using 2.8 right now; as far as I can see there are no changes in 2.9
> regarding this.
--
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-1293) ExplicitPortForwardingTracker does not unbind auto-allocated one
[
https://issues.apache.org/jira/browse/SSHD-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17598004#comment-17598004
]
Jan Philipp commented on SSHD-1293:
---
Yeah, sure I can do this.
I will have to setup the things first. Do you mean a GitHub PR based on your
mirror, or something else I have overseen?
> ExplicitPortForwardingTracker does not unbind auto-allocated one
>
>
> Key: SSHD-1293
> URL: https://issues.apache.org/jira/browse/SSHD-1293
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Jan Philipp
>Priority: Major
>
> I have noticed that the de-allocation (unbind of a forwarding) initiated by
> {{org.apache.sshd.client.session.forward.ExplicitPortForwardingTracker}} in
> the {{close()}} method will not no close the actual forwarding. Said that,
> this leaves the connection and a file handler open.
> The actual main reason is that it uses
> \{{manager.stopLocalPortForwarding(this.getLocalAddress());}} which means it
> stops the tunnel identified the "local address" which is the same as provided
> by the user. If the user is using a local address with port {{0}} (which
> seems legit since the docs state this explicitly), the local address will be
> still something like {{0.0.0.0:0}} or maybe {{{}127.0.0.1:0{}}}, but only the
> "bound address" contains the actual dynamic auto-allocated port.
> If the user uses an explicit port, this would work.
> As a workaround, I have added after {{tracker.close()}} an explicit
> {{session.stopLocalPortForwarding(tracker.getBoundAddress())}}. I don't know
> if this would your final solution or this would be an issue in
> \{{DefaultForwarder#stopLocalPortForwarding}}.
>
> I'm using 2.8 right now; as far as I can see there are no changes in 2.9
> regarding this.
--
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] [Created] (SSHD-1293) ExplicitPortForwardingTracker does not unbind auto-allocated one
Jan Philipp created SSHD-1293:
-
Summary: ExplicitPortForwardingTracker does not unbind
auto-allocated one
Key: SSHD-1293
URL: https://issues.apache.org/jira/browse/SSHD-1293
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 2.8.0
Reporter: Jan Philipp
I have noticed that the de-allocation (unbind of a forwarding) initiated by
{{org.apache.sshd.client.session.forward.ExplicitPortForwardingTracker}} in the
{{close()}} method will not no close the actual forwarding. Said that, this
leaves the connection and a file handler open.
The actual main reason is that it uses
\{{manager.stopLocalPortForwarding(this.getLocalAddress());}} which means it
stops the tunnel identified the "local address" which is the same as provided
by the user. If the user is using a local address with port {{0}} (which seems
legit since the docs state this explicitly), the local address will be still
something like {{0.0.0.0:0}} or maybe {{{}127.0.0.1:0{}}}, but only the "bound
address" contains the actual dynamic auto-allocated port.
If the user uses an explicit port, this would work.
As a workaround, I have added after {{tracker.close()}} an explicit
{{session.stopLocalPortForwarding(tracker.getBoundAddress())}}. I don't know if
this would your final solution or this would be an issue in
\{{DefaultForwarder#stopLocalPortForwarding}}.
I'm using 2.8 right now; as far as I can see there are no changes in 2.9
regarding this.
--
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
