On 9/20/20 10:11 AM, Pavel Raiskup wrote:
Can anyone translate to me if this is really expected or a bug?
Effect is that
Fedora 33 clients can not ssh to Debian 9 hosts by default (I'm not sure about
the supported Debian 10, and the key quality there).
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.