On 9/20/20 10:11 AM, Pavel Raiskup wrote: Sure, but the PubkeyAcceptedKeyTypes doesn't influence acceptable server host keys (and if it did, the client should simply use another one of the server's keys).  PubkeyAcceptedKeyTypes influences what key types the client will try to use for authentication.

On Sunday, September 20, 2020 8:52:21 PM CEST Kevin Fenzi wrote: Well, I did: $ cd /etc/ssh $ rm ssh_host* $ ssh-keygen -N "" -t rsa-sha2-512 -b 4096 -f /etc/ssh/ssh_host_rsa_key $ dpkg-reconfigure openssh-server ... generates the remaining ECDSA and ED25519 ... New host signature detected, but I still get on F33 when trying to ssh: $ ssh -vv ... debug1: Offering public key: /home/praiskup/.ssh/id_rsa RSA SHA256:... debug1: send_pubkey_test: no mutual signature algorithm ... And still -oPubkeyAcceptedKeyTypes=+ssh-rsa helps... Does that meant that the ssh-keygen on Debian 9 is broken? How am I able to tell this is server or client problem? Pavel

On Sun, Sep 20, 2020 19:11:29 +0200, Pavel Raiskup wrote: I just updated to F33, and now I think I get the same issue with BitBucket.org: $ ssh -Tv git(a)bitbucket.org ... send_pubkey_test: no mutual signature algorithm It works if I use: $ ssh -Tv -oPubkeyAcceptedKeyTypes=+ssh-rsa git(a)bitbucket.org Github and Gitlab seem to work fine, so this is Bitbucket specific. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London

On Monday, September 21, 2020 11:11:25 PM CEST José Abílio Matos wrote: Tomáš, is this an expected feature or a bug in F33? What are servers like BitBucket expected to do to comply with F33 clients? Pavel

On Tue, Sep 22, 2020 at 8:40 AM Pavel Raiskup <praiskup(a)redhat.com&gt; wrote: 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. regards, Nikos

On 9/20/20 10:11 AM, Pavel Raiskup wrote: Fedora 33 clients can connect to Debian 9 hosts, they just won't use RSA keys for pubkey authentication.  I think that's a bug. I could be wrong about all of the following, so let me just prefix everything with, "To the best of my understanding:" In OpenSSH 7.8, the semantics of PubkeyAcceptedKeyTypes was changed, and older servers were marked with SSH_BUG_SIGTYPE.  For older servers, ssh->kex->server_sig_algs appears to store a list of key types the server supports, while on newer servers it stores a list of RSA signature types that are supported. sshconnect2.c:key_sig_algorithm will return a copy of the name of an SSH key's type.  For everything except RSA keys, it will filter the key's type against options.pubkey_key_types, but that doesn't make much sense, because the key has already been verified to be a permitted type by sshconnect2.c:pubkey_prepare.  (I haven't gone into the history, but I'm guessing that this code used to filter against ssh->kex->server_sig_algs instead.) In other words, the private key type has already been checked against the local security policy before key_sig_algorithm is called, so key_sig_algorithm shouldn't be acting as a filter.  It should be finding the correct name to refer to the client's key type. I'd suggest dropping the call to match_list, and instead simply return sshkey_ssh_name(key) for all non-RSA key types, and for RSA key types when connecting to a legacy server with SSH_BUG_SIGTYPE set. I'll send this patch to the upstream developers, too.  But do note that none of this has anything to do with the server's host keys.