In this article, we will examine a play used to change the root password using Ansible. It will also encrypt the file the password is stored
In this article, we will discuss SSH Weak Key Exchange Algorithms and how we can resolve them to enhance the security of SSH connections and protect against potential vulnerabilities and unauthorized access.
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.
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.
[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
[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 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!
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!
Related Posts
In this article, we will examine a play used to change the root password using Ansible. It will also encrypt the file the password is stored
In this article, we will review how we can automate a task that checks the timezone using Ansible, offering a detailed walkthrough of the steps
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