“no hostkey alg” when SSH from Oracle Linux 6 to 8

The other day I talked about SSH issues from OL8 to OL6. If you SSH from OL6 to OL8 and it may fail with the following error:

no hostkey alg

Or

Unable to negotiate a key exchange method

On OL6 side, ssh can be put into debug mode to see more information:

root@joetest:~# ssh -vvv 10.10.54.141
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.17.54.141 [10.17.54.141] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/identity-cert type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
debug1: match: OpenSSH_8.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug3: Wrote 864 bytes for a total of 885
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1                                                                                         -sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-r                                                                                         sa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.                                                                                         liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.                                                                                         liu.se
debug2: kex_parse_kexinit: hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96
debug2: kex_parse_kexinit: hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha2                                                                                         56,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
debug2: kex_parse_kexinit: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp521
debug2: kex_parse_kexinit: aes256-gcm@openssh.com,aes256-ctr,aes256-cbc,aes128-gcm@openssh.com,aes128-ctr,aes128-cbc
debug2: kex_parse_kexinit: aes256-gcm@openssh.com,aes256-ctr,aes256-cbc,aes128-gcm@openssh.com,aes128-ctr,aes128-cbc
debug2: kex_parse_kexinit: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,hmac-sha2-5                                                                                         12
debug2: kex_parse_kexinit: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,hmac-sha2-5                                                                                         12
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-sha1
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug2: mac_setup: found hmac-sha1
debug1: kex: client->server aes128-ctr hmac-sha1 none
no hostkey alg

On OL8 side, /var/log/secure shows something similar to below:

Jul 26 16:45:59 localhost sshd[13057]: Unable to negotiate with 10.10.162.130 port 52557: no matching host key type found. Their offer: ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss [preauth]

Or

Sep 27 14:36:11 joetest sshd[2243]: Unable to negotiate with 10.10.162.130 port 42121: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]

It’s quite often to see this when connecting from a legacy Linux OS like OL6 because those weak algorithms are disabled on the newer OS like OL8.

So on OL8, where to start to make it work if you really need to ssh from OL6?

From man page of sshd_config:

man sshd_config

HostKey

	Specifies a file containing a private host key used by SSH.  The defaults are /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key.
	Note that sshd(8) will refuse to use a file if it is group/world-accessible and that the HostKeyAlgorithms option restricts which of the keys are actually used by sshd(8).
	It is possible to have multiple host key files.  It is also possible to specify public host key files instead.  In this case operations on the private key will be delegated to an ssh-agent(1).


HostKeyAlgorithms
	The default is handled system-wide by crypto-policies(7).  To see the current defaults and how to modify them, see manual page update-crypto-policies(8).
    Specifies the host key algorithms that the server offers.
    The list of available key types may also be obtained using "ssh -Q key".

The first thing would be to verify if rsa key file is there and it’s enabled in sshd_config file:

root@joetest:/etc/ssh# ls -lrt
total 608
-rw-r--r--. 1 root root       1770 Jul 31  2020 ssh_config
-rw-r--r--. 1 root root     577388 Jul 31  2020 moduli
drwxr-xr-x. 2 root root         28 May 12 18:51 ssh_config.d
-rw-r--r--. 1 root root        752 May 12 19:04 ssh_host_rsa_key.pub
-rw-------. 1 root root       3401 May 12 19:04 ssh_host_rsa_key
-rw-r--r--. 1 root root        616 May 12 19:04 ssh_host_dsa_key.pub
-rw-------. 1 root root       1393 May 12 19:04 ssh_host_dsa_key
-rw-r--r--. 1 root root        280 May 12 19:04 ssh_host_ecdsa_key.pub
-rw-------. 1 root root        748 May 12 19:04 ssh_host_ecdsa_key
-rw-------. 1 root root       4378 May 12 19:04 sshd_config
-rw-r-----. 1 root ssh_keys    387 Jul 26 18:00 ssh_host_ed25519_key
-rw-r--r--. 1 root root         82 Jul 26 18:00 ssh_host_ed25519_key.pub

root@joetest:/etc/ssh# grep HostKey sshd_config
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

root@joetest:/etc/ssh# ssh -Q key
ssh-ed25519
ssh-ed25519-cert-v01@openssh.com
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-rsa-cert-v01@openssh.com
ssh-dss-cert-v01@openssh.com
ecdsa-sha2-nistp256-cert-v01@openssh.com
ecdsa-sha2-nistp384-cert-v01@openssh.com
ecdsa-sha2-nistp521-cert-v01@openssh.com

RSA key length:

root@joetest:/etc/ssh# ssh-keygen -lf ssh_host_rsa_key.pub
4096 SHA256:fNzoeRsIdJnVhv2D//AGAMYN/oqen4ltfYXqkCGzCUk root@localhost.localdomain (RSA)
root@joetest:/etc/ssh# ssh-keygen -lf ssh_host_rsa_key
4096 SHA256:fNzoeRsIdJnVhv2D//AGAMYN/oqen4ltfYXqkCGzCUk root@localhost.localdomain (RSA)

As the man page mentions, HostKeyAlgorithms is handled by crypto-policies. The next thing is to check the file /etc/crypto-policies/config, if it has a line “FIPS” instead of “DEFAULT”, it means the policies are enforced via FIPS mode. 

root@joetest:/etc/crypto-policies/state# update-crypto-policies --show
FIPS

root@joetest:/etc/crypto-policies/state# cat /etc/crypto-policies/config
FIPS

root@joetest:/etc/crypto-policies/state# cat /etc/crypto-policies/state/current
FIPS

Also the current runtime dump of policy file /etc/crypto-policies/state/CURRENT.pol has no RSA listed for key_exchange parameter:

root@joetest:/etc/crypto-policies/state# grep key_exchange /etc/crypto-policies/state/CURRENT.pol
key_exchange = ECDHE DHE DHE-RSA PSK DHE-PSK ECDHE-PSK

As a comparison, from a FIPS disabled system where DEFUALT policies are in place:

root@joetest:/etc/crypto-policies/state# grep key_exchange /etc/crypto-policies/state/CURRENT.pol
key_exchange = ECDHE RSA DHE DHE-RSA PSK DHE-PSK ECDHE-PSK ECDHE-GSS DHE-GSS

Also from manpage of crypto-policies, you can see what FIPS policy includes:

root@joetest:/etc/ssh# man 7 crypto-policies
       
FIPS
           A level that conforms to the FIPS 140-2 requirements. This policy is used internally by the fips-mode-setup(8) tool which can switch the system
           into the FIPS 140-2 compliance mode. The level provides at least 112-bit security.

           ·   MACs: all HMAC with SHA1 or better

           ·   Curves: all prime >= 256 bits

           ·   Signature algorithms: with SHA-256 hash or better (no DSA)

           ·   TLS Ciphers: >= 128-bit key, >= 128-bit block (AES, including AES-CBC)

           ·   non-TLS Ciphers: same as TLS Ciphers

           ·   key exchange: ECDHE, DHE (no DHE-DSS, no RSA)

           ·   DH params size: >= 2048

           ·   RSA params size: >= 2048

           ·   TLS protocols: TLS >= 1.2, DTLS >= 1.2

Then you can use “fips-mode-setup –check/disable” to disable the FIPS mode. It’s not recommended to use “update-crypto-policies” to set the policy to DEFAULT where the system is in FIPS mode because it will make the system non-compliant with FIPS.

Advertisement

2 thoughts on ““no hostkey alg” when SSH from Oracle Linux 6 to 8”

  1. So, are you implying: If one boots with kernel option “FIPS=0”. then it is okay to use ‘update-crypto-policies’ to modify the policy (because the system is NOT in FIPS mode)?

    Like

    Reply

    1. Yes, if you don’t have FIPS enabled on your system and your orgnization doesn’t have this requirement, then you can use ‘update-crypto-policies’ to even customize predefined policies, for example DEFAULT. If you have FIPS enabled, customize predefined FIPS policy might make it non-FIPS compliant.

      Like

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. ( Log Out /  Change )

Cancel

Connecting to %s