In other words, the Rocky 9 system should have RSA, ECDSA, and ED25519 host keys, or else the sshd would refuse to start.
Furthermore, running sudo sshd -T | grep hostkey on the Rocky 9 should show plenty – but not ssh-dsa nor ssh-rsa.
If you have default ‘sshd_config’ in el9, then you have only three (actual) lines in it:
The first reads additional files (in alphabetical order). One of them does: Include /etc/crypto-policies/back-ends/opensshserver.config
that file sets the ‘PubkeyAcceptedAlgorithms’.
Does that include “ssh-rsa”? If not, does sshd -T show that your addition
takes effect? (SSH uses/prefers first occurrence.)
However, I can right now ssh from el7 to el9, where the el9 has policy DEFAULT. The ssh client on the el7 did store ECDSA hostkey of el9 to knownhosts.
One more thing to consider would be the key length of the RSA pubkey. I have seen servers reject if it wasn’t 2048 or higher. Perhaps it’s an old generated ssh-key that is too short?
I missed conectiva for its distro upgrade - and downgrade - versatility, just with apt4rpm (another best-of-breed over DidNotFinish). Wow, did that work a treat.
Are you sure you have an RSA key and that’s what you’re actually sending? From the server message, it clearly says it accepts RSA. Why don’t you just generate a new RSA key with ssh-keygen -t rsa and try that? On some systems, it defaults to Ed25519 so you need to explicitly set it to RSA.
What is the output of ssh -v when you connect?
Just in case you’re actually using Ed25519, you should know it won’t work if the OS is running in FIPS mode.