How can I use a legacy ssh-rsa key on CentOS 9 Stream?

I am setting up a new CentOS 9 Stream container as a part of a CI system. It needs to make an SSH connection to download some code from a legacy Git host using an ssh-rsa key (which is considered an acceptable risk on this network with this host).

I start by generating a key.

ssh-keygen -t ssh-rsa -f test_rsa_key

Running with the key I get a "no mutual signature algorithm" error.

ssh -v -i test_rsa_key user@server

debug1: Next authentication method: publickey
debug1: Offering public key: test_rsa_key RSA SHA256:<snip> explicit
debug1: send_pubkey_test: no mutual signature algorithm
debug1: No more authentication methods to try.
user@server: Permission denied (publickey).

I can explicitly enable ssh-rsa with -oPubkeyAcceptedKeyTypes=+ssh-rsa, but now I get a libcrypto error.

ssh -oPubkeyAcceptedKeyTypes=+ssh-rsa -v -i test_rsa_key user@server

debug1: Next authentication method: publickey
debug1: Offering public key: test_rsa_key RSA SHA256:<snip> explicit
debug1: Server accepts key: test_rsa_key RSA SHA256:<snip> explicit
debug1: identity_sign: sshkey_sign: error in libcrypto
sign_and_send_pubkey: signing failed for RSA "test_rsa_key": error in libcrypto
debug1: No more authentication methods to try.
user@server: Permission denied (publickey).

Is it possible that support for the legacy ssh-rsa signature method is disabled in CentOS 9 Stream at the libcrypto level? How can I make a connection with this key on the latest CentOS?

The use of SHA-1 for signatures is restricted in the default crypto policy.

Trying to SSH from RHEL9 (or variant) client to a RHEL6 (or variant) OpenSSH server fails with the following error message:

ssh_dispatch_run_fatal: Connection to 1.2.3.4 port 22: error in libcrypto

There are 2 known options:

1. On RHEL9, enable legacy SHA1 crypto-policy (NOT RECOMMENDED):

update-crypto-policies --set DEFAULT:SHA1

2. On RHEL6, use the ECDSA algorithm instead of RSA to create the host key (preferred)

   i. Generate sshd ECDSA host keys:

   ssh-keygen -t ecdsa -b 384 -f /etc/ssh/ssh_host_ecdsa_key
   semanage fcontext -a -f -- -t sshd_key_t /etc/ssh/ssh_host_ecdsa_key
   semanage fcontext -a -f -- -t sshd_key_t /etc/ssh/ssh_host_ecdsa_key.pub
   

   ii. Edit /etc/ssh/sshd_config and set:

   HostKey /etc/ssh/ssh_host_ecdsa_key
   

   iii. Restart sshd

   service sshd restart
   

If you aren't locked in to an RSA keypair, you can use ECDSA instead.

In my case I was running into this same error while attempting to SSH from an RHEL 9 client to an RHEL 6 server. I was able to solve this issue by generating and using an ECDSA keypair instead of RSA:

ssh-keygen -t ecdsa
ssh user@host -i ~/.ssh/id_ecdsa

Another answer mentions generating ECDSA host keys on the server. In my case, the RHEL 6 server was already using ECDSA host keys.

With the ECDSA keypair and host keys, it was not necessary for me to set the "legacy" crypto policy as mentioned in the other answers.

Found an answer, courtesy of a similar issue somebody else had on the Red Hat Bugzilla (login required).

The issue is caused by the deprecation of SHA1. You can work around this by setting a crypto policy of LEGACY following the instructions here.

The command is:

update-crypto-policies --set LEGACY

Before running, review the linked page because it does enable some quite old crypto settings, which might be too insecure for your use-case.

In my context, I have a RHEL5 system, a Centos 6.9 system and a Centos 6.6 system. I'm working to build a replacement for the Centos 6.9 system on new hardware with Rocky 9. I need to run SSH in from and to each of the old systems from the Rocky 9 system.

The ecdsa key replacement worked for connection to the Centos systems from the Rocky 9 system, but not to the RHEL5 system. And I was still unable to connect from the old systems tp Rpcly 9. Along the way, I did variations of the suggestion in https://unix.stackexchange.com/questions/674582/how-to-enable-ssh-rsa-in-sshd-of-openssh-8-8 which changed the symptoms but didn't fix the issues.

The final change which seems to have fixed my connection issues was the

update-crypto-policies --set DEFAULT:SHA1

command described above.