How To Resolve SSH Weak Key Exchange Algorithms on CentOS7 or RHEL7

Introduction

On October 13, 2021, Tenable published the following SSH Vulnerability: SSH weak key exchange algorithms enabled  giving it a low severity rating. This does not mean it can’t be elevated to a medium or a high severity rating in the future. Also, the fix for this SSH vulnerability requires a simple change to the /etc/ssh/sshd_config file.  

According to Tenable, when the remote SSH server allows weak key exchange algorithms, it is considered weak. They are explicit about the entries recommended according to Section 4 of the Internet Engineering Task Force (IETF) draft document Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) draft-ietf-curdle-ssh-kex-sha2-20. 

The following steps (below) will resolve this finding as well as, a related SSH finding which requires disabling cipher block chaining. Refer to Tenable SSH Server Cipher Block Chaining (CBC) Mode Ciphers Enabled for more details.

SSH Weak Key Exchange: Installation and Configuration

First things first, ensure your SSH version is up-to-date. 

[root@localhost ~]# yum update *ssh* -y
Last metadata expiration check: 0:42:36 ago on Wed 17 Nov 2021 04:59:46 AM UTC.
Dependencies resolved.
Nothing to do. Complete!

Next, run the following commands to list the available Ciphers and MACs for your SSH version.

Check Ciphers

[root@localhost ~]# ssh -Q cipher
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

Check MACs

[root@tech ~]# ssh -Q mac
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

Examine the list as we’re not going to use all that is listed here (above). We just need to ensure that we DO NOT choose anything with sha1 in our final entry. Here’s an example of how your final entry for Ciphers, KexAlogrithms, and MACs might look like this (below) (No space between commas):

Ciphers aes128-ctr,aes192-ctr,aes256-ctr
KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
MACs hmac-sha2-256,hmac-sha2-512

Copy and paste the following entries (above) to the end or bottom of the /etc/ssh/sshd_config file and restart the ssh daemon or service.

[root@localhost ~]# systemctl restart sshd.service

SSH Weak Key Exchange: Testing

SSH to localhost with verbosity to see if the change is applied and working. 

[root@tech ~]# ssh -vvvv localhost
OpenSSH_8.0p1, OpenSSL 1.1.1k FIPS 25 Mar 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 52: Including file /etc/ssh/ssh_config.d/05-redhat.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug2: checking match for 'final all' host localhost originally localhost
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 3: not matched 'final'
debug2: match not found
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 5: Including file /etc/crypto-policies/back-ends/openssh.config depth 1 (parse only)
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug3: gss kex names ok: [gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-,gss-gex-sha1-,gss-group14-sha1-]
debug3: kex names ok: [curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1]
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 52: Including file /etc/ssh/ssh_config.d/05-redhat.conf depth 0

As you can see (above), the change was applied successfully!

Conclusion

Remember, the specific steps may vary depending on your operating system and SSH version. Always refer to the documentation for your specific implementation for accurate and detailed instructions. Finally, if you’re looking to automate this procedure, here’s a post that can help you with that!

Was this article helpful to you? If so, leave us a comment below. We’d love to hear from you!