Problems with using RSA SHA256 key

[perlun]

Support for RSA SHA256 keys were added in #1643. However, I have trouble getting this to work with my (RSA-based) key though. 🤔 Here's the key format as described by ssh-keygen:

$ ssh-keygen -l -f ~/.ssh/id_rsa.pub
2048 SHA256:nEecUUWt8//qdNKTcQ5nPAGpTLXmWQm5jBt/Qzx4JvQ per.lundberg@hibox.tv (RSA)

Here's what it logs on the (Ubuntu 22.04) server side (OpenSSH_8.9p1 Ubuntu-3ubuntu0.1, OpenSSL 3.0.2 15 Mar 2022):

Feb 21 10:58:02 ubuntu-2204-centre-test-c4d5124d sshd[19345]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Feb 21 10:58:02 ubuntu-2204-centre-test-c4d5124d sshd[19345]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Feb 21 10:58:02 ubuntu-2204-centre-test-c4d5124d sshd[19347]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Feb 21 10:58:02 ubuntu-2204-centre-test-c4d5124d sshd[19347]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

Interestingly enough, connecting via OpenSSH (OpenSSH_9.1p1 Debian-2, OpenSSL 3.0.7 1 Nov 2022) to the same host with the same key works fine. 🤔

• Paramiko version 2.12.0
• Running from pytest-testinfra 7.0.1

ssh host -v gives me this on connecting, when the authentication is successful:

debug1: Offering public key: /home/plundberg/.ssh/id_rsa RSA SHA256:nEecUUWt8//qdNKTcQ5nPAGpTLXmWQm5jBt/Qzx4JvQ agent
debug1: Server accepts key: /home/plundberg/.ssh/id_rsa RSA SHA256:nEecUUWt8//qdNKTcQ5nPAGpTLXmWQm5jBt/Qzx4JvQ agent

Any ideas? I works fine if I add PubkeyAcceptedAlgorithms +ssh-rsa on the server, but that's obviously something that I do not want to do, since it works (without this setting) with plain OpenSSH.

[bskinn]

Flagging this as something to address in the overall key/auth overhaul of #387

[bitprophet]

• Are all 4 of those log lines from the sshd from a single connection attempt, or is that 4 separate attempts?
• Can you post more debug logs from Paramiko's end (enable DEBUG level via stdlib logging somewhere at module level)? It may help, and should at least show whether this is something like other/older keys on your system being offered without you realizing it.

And bskinn is right that we're hoping to add a new auth flow "soon"™ that should make this easier to observe and change, as well as be more in line with OpenSSH's behavior.