On Tuesday, September 22, 2020 1:07:07 PM CEST Nikos Mavrogiannopoulos wrote:
On Tue, Sep 22, 2020 at 8:40 AM Pavel Raiskup
<praiskup(a)redhat.com> wrote:
> > I hit that two week ago for bitbucket and other servers. In my case I got it
> > connecting to lyx git server. At the time I wrote about it in the fedora-test
> > mailing list.
> >
> > My workaround solution was to add to ~/.ssh/config
> >
> > Host *
> > PubkeyAcceptedKeyTypes +rsa-sha2-256,rsa-sha2-512
>
> Tomáš, is this an expected feature or a bug in F33? What are servers like
> BitBucket expected to do to comply with F33 clients?
Yes it is a feature of Fedora 33. It requires services to use better
algorithms than SHA-1 which is considered broken today. This is
described in the changes that Tomas is driving at:
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
In this particular case I believe you have identified a bug in
bitbucket's ssh setup. They are using old SSH infrastructure that can
only do SHA-1. You may want to contact them about this.
Yes, probably (I personally din't not even try to check BitBucket). Thank you
for the additional info!
The source of confusion on my side was that
- 'ssh -oPubkeyAcceptedKeyTypes=+rsa-ssh2-512' actually doesn't
allow the 'rsa-ssh2-512' on Fedora, but (among others?) 'ssh-rsa',
because '=+' entirely drops the Fedora defaults and starts using openssh
defaults (openssh defaults aren't a subset of Fedora defaults).
- The openssh-servers claim what server-sig-algs= they support, but that's
not a dynamic list reflecting the pre-configured host keys. So no
matter if server has a rsa-ssh2-512 host key, it will continue to claim
that it only accepts 'ssh-rsa'. And that confuses clients.
Pavel