How To Resolve SSH Weak Key Exchange Algorithms on CentOS7 or RHEL7
Table of Contents
- counters(item,.) . Installation and Configuration
- counters(item,.) . Testing
- counters(item,.) . Conclusion
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.
Installation and Configuration
First things first, ensure your SSH version is up-to-date.
[root@tech ~]# 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.
[root@tech ~]# 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 [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@tech ~]# systemctl restart sshd.service
Testing
We can SSH to our 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 (in bold) the change was applied successfully!
Conclusion
Finally, if you’re looking to automate this procedure, here’s a post that can help you with that!
RELATED POSTS
Write a play that checks for the timezone of a system and outputs the results to a file
Table of Contents Red Hat Ansible Automation: ObjectivesIn this exercise, we will examine a playbook that checks the timezone on system (Linux Machine) and outputs
Write a play that changes the root password hash and encrypts the file it is stored in
Table of Contents Red Hat Ansible Automation: Objectives In this exercise, we will examine a playbook that changes the root password on your system (Linux
Write a play automating changes to the SSHD Configuration file
In today’s Ansible series, we will learn about automating changes using Ansible. Specifically, we will automate changes to the sshd config file. Table of Contents