[
https://issues.apache.org/jira/browse/SSHD-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17264484#comment-17264484
]
Ian Wienand commented on SSHD-1118:
-----------------------------------
Sorry I may not have been quite clear, and this is for sure all a big mess. I
don't think this is really related to keys, but rather the hash negotiation.
Fedora have dropped {{ssh-rsa}} from the PubkeyAcceptedKeyTypes clients use by
default
As I understand it, openssh clients will not use {{rsa-sha2-*}} unless the
server responds with those in {{server-sig-algs}}. As I also understand it,
mina sshd doesn't yet implement that (even in 2.6.0?).
ergo per the RFC8332 openssh drops back to {{ssh-rsa}}
bq. When authenticating with an RSA key against a server that does not
implement the "server-sig-algs" extension, clients MAY default to an "ssh-rsa"
signature to avoid authentication penalties. When the new rsa-sha2-*
algorithms have been sufficiently widely adopted to warrant disabling
"ssh-rsa", clients MAY default to one of the new algorithms.
Since {{ssh-rsa}} that is now disabled, the end result is unfortunately that
Fedora 33 users by default can't log in.
My immediate query is soliciting what is the best advice to give to such users.
It seems the only option is to explicitly use {{\-o
PubkeyAcceptedKeyTypes=ssh-rsa}} (via command line or per-host config setup) to
enable {{ssh-rsa}}? I can not seem to find any way to convince openssh clients
to use {{rsa-sha2-*}} against gerrit/mina otherwise -- but if there is, I'd
love to know! The problem with telling people to do this (which is covered in
the depths of [this
bug|https://bugzilla.redhat.com/show_bug.cgi?id=1881301#c29]) is that this
_overrides_ the system crypto-policy; this is why weirdly {{\-o
PubkeyAcceptedKeyTypes=+rsa-sha2-512}} also works; the existence of the
argument overrides the system crypto-policy and falls back to the openssh
defaults, which still includes {{ssh-rsa}} -- it's not actually using
{{rsa-sha2-512}} at all.
So if there are other options, that would be better!
I certainly understand this is stemming from Fedora's choice here; but it is
likely other distros will start to follow.
> Unable to connect with Fedora 33 which has dropped ssh-rsa from
> PubkeyAcceptedKeyTypes
> --------------------------------------------------------------------------------------
>
> Key: SSHD-1118
> URL: https://issues.apache.org/jira/browse/SSHD-1118
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 2.4.0
> Reporter: Ian Wienand
> Priority: Major
>
> This problem was noted with Gerrit using a 2.4.0 mina sshd server [1] after a
> recent upgrade. Some users using Fedora 33 started being not able to log in.
> It turns out that Fedora >=33 has dropped rsa-ssh from it's default
> {{PubkeyAcceptedKeyTypes}} in
> {{/etc/crypto-policies/back-ends/openssh.config}}. You either have to modify
> your policy globally to "legacy" with "update-crypto-policies" or manually
> set {{PubkeyAcceptedKeyTypes=ssh-rsa}} for failing servers.
> I understand that {{server-sig-algs}} support isn't fully implemented in mina
> sshd as yet, so the client will not be seeing the negotiation list.
> However, it seems rsa-sha2-256/512 are supported? It seems like forcing this
> with {{ssh -oPubkeyAcceptedKeyTypes=rsa-sha2-512}} should work, but it does
> not (see related gerrit bug)?
> I can provide ssh connect logs, etc. if it will help; at this point I think
> it's mostly about understanding Fedora's change and any mina limitations so
> we can find the best solution for users. Although Fedora 33 users are
> obviously a small minority now, it probably flags something other distros
> will take up sooner or later.
>
> Thanks!
>
> [1] [https://bugs.chromium.org/p/gerrit/issues/detail?id=13930]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
