crypto-policies FUTURE and inability to SSH into system from CentOS 6 system

[AkosPrime]

Using the command: update-crypto-policies --set FUTURE (done because the security scanner people complain about some of the ciphers supported in the DEFAULT setting) we found that CentOS 6 systems could no longer SSH into the CentOS 8 systems, and generated this message instead: "no hostkey alg"

I did a 'ssh -vvv' and have the output of that if it's necessary to diagnose the problem. But was wondering if there was a known issue and if something needed to be turned on at either end to make CentOS 6 clients able to connect to CentOS 8 servers via SSH when crypto policy is set to FUTURE?

[TrevorH]

If you look in /etc/crypto-policies/back-ends/opensshserver.config it has a list of the various parameters that will be used. It would appear that CentOS 6 is just too old to connect to CentOS 8 in FUTURE mode. I tested FUTURE and FIPS and both fail, both LEGACY and DEFAULT work.

You probably want to read the man pages for both update-crypto-policies and crypto-policies as they have info about what ciphers etc are allowed and which are disabled in each mode.

Edit: there's a message in /var/log/secure which tells you the problem. For me that is

Oct 9 18:00:12 centos8 sshd[11406]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes [preauth]

[AkosPrime]

I'm wondering it I can just leave the system in DEFAULT crypto policy, but manually edit the file: /usr/share/crypto-policies/DEFAULT/opensshserver.txt and remove the CBC cipher support. This would allow 6.x systems to connect to 8.x systems during the transitional period, while also keeping the security scanning hg's off my back. I'll test that soon and post my results.

[harrywangca]

I have the same issue but fixed it by upgrading putty to latest version.

[darthbolek]

I'm wondering it I can just leave the system in DEFAULT crypto policy, but manually edit the file: /usr/share/crypto-policies/DEFAULT/opensshserver.txt

Technically that should work (I did not try it though), but then you are creating inconsistency in your network. You will have different versions of DEFAULT policy. Why not create create your own policy?