How to Resolve SSH Weak Key Exchange Algorithms on RHEL 9 or CentOS 9

Introduction

SSH (Secure Shell) is a critical protocol for securely managing servers, especially on Linux-based distributions like RHEL 9 and CentOS 9. While SSH is a robust tool for remote administration, there are common security issues that arise during its setup and operation. One of the most concerning is the use of weak key exchange algorithms, which can leave your system vulnerable to attacks such as man-in-the-middle (MITM) and brute-force attacks.

In this blog post, we’ll dive into the issue of weak key exchange algorithms in SSH, provide detailed instructions for resolving the issue on RHEL 9 or CentOS 9, and guide you through securing your SSH setup to enhance server security.

What Are SSH Key Exchange Algorithms?

Before we delve into how to fix weak key exchange algorithms, let’s take a moment to understand what they are. SSH key exchange algorithms are the cryptographic protocols used to securely exchange cryptographic keys between the client and the server. The key exchange process is a critical component of the SSH protocol, enabling secure communication between two systems over an untrusted network.

During the key exchange, the server and client agree on which encryption methods to use, and they generate shared secrets, which are then used to encrypt the communication session. If weak or outdated key exchange algorithms are used, it can compromise the security of the entire session.

Identifying Weak Key Exchange Algorithms

In SSH, weak key exchange algorithms can expose your server to various types of cryptographic attacks, potentially compromising the integrity of your secure connections. These weak algorithms may be outdated or rely on smaller key sizes that modern computational capabilities can break or exploit. As a result, it’s crucial to identify and disable any algorithms that are considered weak or insecure.

Here’s a breakdown of some of the most common weak key exchange algorithms in SSH, along with a brief explanation of each:

Photo by admingeek from Infotechys

diffie-hellman group 1 (1024-bit)

What is it? Diffie-Hellman Group 1 (often referred to as DH Group 1) is a key exchange algorithm that uses a 1024-bit key size. It’s based on the Diffie-Hellman key exchange protocol, which allows two parties to securely share a secret key over an untrusted network. Why is it weak? The 1024-bit key size is considered too small by modern cryptographic standards. With advances in computational power, an attacker could potentially break the encryption through a brute-force attack. As a result, Diffie-Hellman Group 1 is no longer considered secure for production environments. What should you do? Disable the diffie-hellman-group1-sha1 algorithm and replace it with stronger alternatives, like Diffie-Hellman Group 14 or Curve25519.

RSA (2048-bit)

What is it? RSA is a widely-used asymmetric encryption algorithm used for key exchange, digital signatures, and public-key cryptography. The 2048-bit key size is still commonly used for SSH encryption. Why is it weak? Although a 2048-bit RSA key is generally considered secure for now, RSA-based encryption is vulnerable to future attacks from quantum computers. Quantum computers could potentially solve RSA encryption algorithms much more efficiently than classical computers, making RSA less secure in the long run. Additionally, the RSA algorithm’s reliance on large prime numbers can make it slower than newer cryptographic methods, like elliptic curve cryptography. What should you do? Although RSA-2048 is not immediately insecure, you should start migrating to algorithms like ECDSA or Curve25519, which are faster and more resistant to future quantum attacks.

ecdsa with low curve (e.g., 256-bit)

What is it? ECDSA (Elliptic Curve Digital Signature Algorithm) is an elliptic curve-based cryptographic algorithm used for SSH authentication and key exchange. It’s generally more efficient than RSA and provides better security per bit. However, the strength of ECDSA depends heavily on the curve used. Why is it weak? Some older or poorly chosen elliptic curves used for ECDSA, such as the secp256k1 curve, are known to be vulnerable to attacks. Furthermore, shorter curves like 256-bit can be broken more easily than larger curves, so they should be avoided in favor of more secure curves like secp384r1 or Curve25519. What should you do? Ensure you’re using secure, standardized curves like Curve25519 or secp384r1. Avoid using shorter curves like 256-bit ECDSA or any deprecated curves.

diffie-hellman-group-exchange-sha1

What is it? This is another variant of Diffie-Hellman that allows for more flexibility in choosing the size of the group used during the key exchange. The algorithm dynamically generates the group during the key exchange process. Why is it weak? While diffie-hellman-group-exchange-sha1 is an improvement over Group 1, it still uses SHA-1 as a hashing algorithm, which is vulnerable to collision attacks. In addition, the generated group may still be vulnerable if it uses weak parameters or an insufficiently large key size. What should you do? Replace this algorithm with more secure alternatives like diffie-hellman-group14-sha256 or Curve25519. Avoid using SHA-1-based key exchange algorithms entirely.

diffie-hellman-group1-sha1

What is it? This is a variation of Diffie-Hellman Group 1, using SHA-1 as the hash function for additional security. It has the same 1024-bit key size limitation as Group 1 and is thus equally insecure. Why is it weak? As with diffie-hellman-group-exchange-sha1, the use of SHA-1 and the small 1024-bit key size make this algorithm obsolete and vulnerable to modern attacks. SHA-1 itself is no longer considered secure due to its susceptibility to collision attacks. What should you do? Disable diffie-hellman-group1-sha1 in your configuration, and use stronger algorithms like Curve25519 or diffie-hellman-group14-sha256.

gss-gex-sha1-*

What is it? The GSS-API (Generic Security Services API) is a standard for network security that can be used with SSH for mutual authentication. The gss-gex-sha1-* algorithms are used in GSS-based key exchange protocols that rely on SHA-1 hashing. Why is it weak? Since this algorithm uses SHA-1, it inherits the same vulnerabilities as other SHA-1-based algorithms. SHA-1 is deprecated and should be avoided in favor of more secure algorithms. What should you do? Avoid using any GSS algorithms that rely on SHA-1, and configure your SSH server to use more secure algorithms like diffie-hellman-group14-sha256.

gss-group1-sha1-*

What is it? Similar to gss-gex-sha1-*, the gss-group1-sha1-* algorithms are used in GSS-based key exchange protocols, but they specifically rely on Group 1 Diffie-Hellman with SHA-1. Why is it weak? The Group 1 Diffie-Hellman protocol with SHA-1 hashing is widely considered insecure due to the small 1024-bit key size and weaknesses in SHA-1. What should you do? Disable these algorithms and migrate to diffie-hellman-group14-sha256 or Curve25519.

gss-group14-sha1-*

What is it? This algorithm uses Group 14 Diffie-Hellman with SHA-1 hashing. While Group 14 is more secure than Group 1 due to its larger 2048-bit key size, it still suffers from the weaknesses of SHA-1. Why is it weak? Although Group 14 Diffie-Hellman offers better security than Group 1, the use of SHA-1 as the hashing function still introduces vulnerabilities, as SHA-1 is no longer considered safe for cryptographic use. What should you do? Replace gss-group14-sha1-* algorithms with newer, safer alternatives, such as diffie-hellman-group14-sha256 or Curve25519.

RSA1024-sha1

What is it? This refers to RSA-based key exchange algorithms that use a 1024-bit key size combined with SHA-1. Why is it weak? The 1024-bit RSA key size is outdated and vulnerable to modern cryptographic attacks, while SHA-1 is no longer considered secure. What should you do? Disable rsa1024-sha1 and ensure you are using RSA-2048 or better, with the option of replacing RSA with more modern algorithms like Curve25519.

RHEL 9 and CentOS 9, like other modern Linux distributions, aim to use secure algorithms by default, but it’s essential to confirm the configurations and remove weak algorithms for peace of mind.

---

Checking the Current SSH Key Exchange Algorithms on RHEL 9 / CentOS 9

To check the key exchange algorithms currently supported by your SSH server, you can use the following command:

ssh -Q kex

diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
curve25519-sha256
curve25519-sha256@libssh.org
sntrup761x25519-sha512@openssh.com

This command will list all available key exchange algorithms. If you see older, insecure algorithms such as diffie-hellman-group1-sha1, you’ll need to disable them. Additionally, you can view the current SSH configuration settings by inspecting the sshd_config file:

cat /etc/ssh/sshd_config | grep KexAlgorithms

If the KexAlgorithms directive is not present, your server may be using the default settings, which might include weak algorithms.

---

Steps to Resolve Weak Key Exchange Algorithms on RHEL 9 / CentOS 9

To resolve issues with weak key exchange algorithms, follow these steps:

Backup SSH Configuration Files

Before making any changes to your server’s SSH configuration, it’s essential to back up the existing sshd_config file to prevent misconfigurations.

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Edit the SSH Configuration File

Next, you’ll need to edit the SSH configuration file to disable weak key exchange algorithms.

sudo vim /etc/ssh/sshd_config

Search for the KexAlgorithms directive. If it’s not present, add it at the end of the file. A secure configuration might look like this:

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

This configuration ensures that only secure algorithms are used. In this case:

ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521: These are elliptic curve Diffie-Hellman algorithms with various bit sizes (256-bit, 384-bit, and 521-bit). They are secure and efficient for modern cryptographic standards. diffie-hellman-group-exchange-sha256: This algorithm offers a secure key exchange with an automatically generated group, but uses the secure SHA-256 hashing algorithm. diffie-hellman-group16-sha512 and diffie-hellman-group18-sha512: These are modern, secure Diffie-Hellman groups using large 4096-bit and 8192-bit key sizes, respectively, along with the strong SHA-512 hashing algorithm. diffie-hellman-group14-sha256: This is a widely used secure Diffie-Hellman group with a 2048-bit key and SHA-256 for hashing.

By limiting your key exchange algorithms to these more secure ones, you significantly reduce the risk of unauthorized access.

Disable Deprecated Algorithms

If you’re concerned about using older algorithms (such as diffie-hellman-group1-sha1), you can explicitly disable them by adding them to the Ciphers directive in the sshd_config file:

Ciphers aes256-ctr,aes192-ctr,aes128-ctr

This configuration ensures that only secure ciphers (e.g., AES) are used during communication. In modern SSH configurations, it’s also important to use secure and efficient MAC algorithms like HMAC-SHA2-256 and HMAC-SHA2-512 to ensure the security and integrity of the connection.

MACs hmac-sha2-256,hmac-sha2-512

By setting the MACs directive to these two algorithms, you’re ensuring that your SSH connections are using modern and secure algorithms for message integrity.

Restart SSH Service

Once you’ve edited the sshd_config file, restart the SSH service to apply your changes:

sudo systemctl restart sshd

Verify the Changes

To ensure that your changes have been applied successfully, you can attempt to connect to your SSH server from a client machine and check which key exchange algorithm is being used. Run the following command:

ssh -vvv user@your-server-ip

Look for the kex: section in the verbose output. It will display which key exchange algorithm is being negotiated. Ensure that it matches the secure algorithms you configured.

---

Creating a Secure SSH Setup (Best Practices)

In addition to disabling weak key exchange algorithms, here are some other best practices for securing your SSH configuration:

Use Strong Passwords and Key-Based Authentication: Always disable root login and enforce the use of SSH keys for authentication. Restrict Access by IP: Limit SSH access to specific IPs or subnets using firewall rules or the AllowUsers/AllowGroups directives in sshd_config. Use Two-Factor Authentication (2FA): Enable two-factor authentication (2FA) for an added layer of security. Set SSH Timeouts: Configure automatic session termination after a period of inactivity to prevent unauthorized users from hijacking idle sessions.

ClientAliveInterval 300
ClientAliveCountMax 0

Disable Unused SSH Features

If your environment doesn’t require port forwarding, tunneling, or agent forwarding, disable these features to reduce attack surfaces.

AllowTcpForwarding no
X11Forwarding no

---

Summary of Weak SSH Key Exchange Algorithms

Algorithm	Weakness	Suggested Alternative
diffie-hellman-group1-sha1	1024-bit key, SHA-1 vulnerability	diffie-hellman-group14-sha256 or Curve25519
diffie-hellman-group-exchange-sha1	SHA-1, dynamic group weak parameters	diffie-hellman-group14-sha256 or Curve25519
gss-gex-sha1-*	Uses SHA-1 for key exchange	diffie-hellman-group14-sha256
gss-group1-sha1-*	SHA-1, Group 1 Diffie-Hellman	diffie-hellman-group14-sha256 or Curve25519
gss-group14-sha1-*	SHA-1, Group 14 Diffie-Hellman	diffie-hellman-group14-sha256 or Curve25519
rsa1024-sha1	1024-bit key, SHA-1 vulnerability	RSA-2048, Curve25519

By identifying and removing these weak key exchange algorithms, you can significantly improve the security of your SSH connections and prevent potential attacks.