sshd: Server refused public-key signature despite accepting key

Question

I am renting a VPS running CentOS Stream 8, for which I set up SSH pubkey authentication for the user "foo". I access it via PuTTY on Windows.

Recently I rented another VPS running Rocky Linux 9, and I set up sshd in an identical way, then copying the /home/foo/.ssh/authorized_keys file from the old VPS to the new one. In this way I had just to clone the PuTTY profile configuration, changing only the IP address from the old to the new one, and reusing PuTTY's PPK key.

However, when I SSH to the new server via PuTTY, I get the error:

Using username "foo".
Authenticating with public key "[email protected]"
Server refused public-key signature despite accepting key!
Using keyboard-interactive authentication.
Password:

and I have to enter "foo" user's password. However, I'd like to ditch password-based authentication, as in the old server.

The private and public keys are the same on both ends. SELinux is not interfering here. Permissions of ~/.ssh and ~/.ssh/authorized_keys are correct.

Note that SSHing in via pubkey from the new server to itself works perfectly. Clearly in this case it uses id_rsa, not PuTTY's PPK key.

dmesg and /var/log/messages do not show anything useful.

What could be the problem?

Note: this is not a duplicate of Server refused public-key signature despite accepting key - putty , as none of the answers apply.

Answer 1

Is your version of PuTTY up to date?

Currently the SSH protocol is being changed to use newer, stronger hash/signature algorithms with existing RSA keys. ssh -Q key-sig will show them as rsa-sha2-256 and rsa-sha2-512 to replace the old ssh-rsa.

The version of sshd in RHEL / Rocky 9.x will require the use of these stronger hash algorithms by default. The keys themselves are fine, there will be no need to replace them. The hashes in question are not embedded in the key material, but are calculated during connection negotiation, so the hash algorithm can be changed without replacing the keys.

It is possible to allow the old hash algorithms too, but the more secure option is to upgrade your PuTTY to the latest version, which is 0.81 at the time of this writing.

If you want/need to allow incoming connections from older SSH clients that don't have the rsa-sha2-* algorithm combinations available to RHEL/Rocky 9.x, and cannot have the clients switch to e.g. ECDSA keys instead, you would have to set the crypto policy to:

update-crypto-policies --set DEFAULT:SHA1

Some sources also suggest the alternative:

update-crypto-policies --set LEGACY

It also works, but is not recommended for this purpose because it is overkill: it also allows several other weak cryptographic methods.

References:

• this answer at Server Fault.SE
• Red Hat documentation