Created attachment 3446 [details] return correct key type name when connected to openssh server < 7.8 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.
For example, I have an rsa-sha2-256 private key. If I connect to a server running openssh 7.4, and PubkeyAcceptedKeyTypes=ssh-rsa, then the key is correctly handled by the openssh 8.3 client. However, if PubkeyAcceptedKeyTypes=rsa-sha2-256, then the key cannot be used. The openssh 8.3 client accepts the same key and configuration when used to connect to openssh >= 7.8 servers. $ ssh-keygen -l -f ~/.ssh/id_rsa_2015-11-02 4096 SHA256:.... gordon (RSA) $ ssh -oPubkeyAcceptedKeyTypes=ssh-rsa -i ~/.ssh/id_rsa_2015-11-02 openssh74 Enter passphrase for key '/home/gordon/.ssh/id_rsa_2015-11-02': gordon@openssh74:~$ logout Connection to 192.168.122.11 closed. $ ssh -oPubkeyAcceptedKeyTypes=rsa-sha2-256 -i ~/.ssh/id_rsa_2015-11-02 openssh74 gordon@openssh74's password: gordon@openssh74:~$ logout Connection to 192.168.122.11 closed. $ ssh -oPubkeyAcceptedKeyTypes=rsa-sha2-256 -i ~/.ssh/id_rsa_2015-11-02 openssh78 Enter passphrase for key '/home/gordon/.ssh/id_rsa_2015-11-02': gordon@openssh78$
Please, have a look to the description in the following comment: https://bugzilla.redhat.com/show_bug.cgi?id=1881301#c27 I believe this is a bug only in OpenSSH 7.4p1, which is in Debian 9 and which is the only version that reports wrong server-sig-algs in the extension. This means, either long-shot to fix this in Debian 9 (by mostly reverting [1] as we did in RHEL7), the another long shot is implement a compat fix for this particular openssh version in upstream (not sure if it is worth it for that old release, but Debian 9 is still quite common). [1] https://github.com/openssh/openssh-portable/commit/130f5d
Created attachment 3448 [details] Use RSA keys for OpenSSH 7.4 servers, if local policy permits Jakub Jelen helped me understand the code a little better, and to understand that the premise of the previous patch was flawed. This version more specifically targets the lack of SHA2 hashes in server-sig-algs when connecting to OpenSSH 7.4.
Darren, Damien, can you check this patch if it would make sense for you? We encountered this now in Fedora, because we disabled SHA1 in signature algorithms. Others will have the same issue when you will do the same upstream.
looks reasonable to me. Damien?
ok me too, but I think the compat code should be in its own function
retarget to 8.6
Created attachment 3476 [details] Use RSA keys for OpenSSH 7.4 servers, if local policy permits I've rebased the previous patch and moved the compat code to its own function. Using a custom config matching Fedora's current default to connect to a Debian 9 (openssh 7.4) VM, I've verified that an RSA key will be used successfully with the patch, and will not be attempted without it. Host 192.168.122.246 PubkeyAcceptedAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com
retarget after 8.6p1 release
Created attachment 3527 [details] simplified patch Semi-reversing what I said previously, there is a simpler approach if the test remains in the function.
This has been committed as 4265215d7 and will be in OpenSSH 8.7 - thanks.
It seems that this fix doesn't entirely resolve the issue. I tested on Fedora 34 with OpenSSH 8.7p1 and I get an error when using an OpenSSH certificate to connect to a CentOS 7 server running OpenSSH 7.4p1. The error message is as follows: `send_pubkey_test: no mutual signature algorithm` Adding `PubkeyAcceptedKeyTypes +ssh-rsa` allows the connection to go through, but I don't think that it should be necessary. For reference, the cert is of type `ssh-rsa-cert-v01@openssh.com`. The public key on the cert is `RSA-CERT SHA256` and the Signing CA uses `ssh-ed25519` Please let me know if this can be fixed with a similar compat code change
closing bugs resolved before openssh-8.9