How to Disable Weak SSH Algorithms on RHEL 8/9/10 (SHA-1 HMACs, SHA-1 Kex, CBC, 3DES)

In this tutorial, we will quickly look at how to disable weak SSH algorithms on RHEL 8/9/10, including SHA-1 HMACs, SHA-1 key exchange methods, CBC ciphers, and 3DES encryption. These algorithms are considered outdated and insecure by modern cryptographic standards, and leaving them enabled can expose your systems to potential vulnerabilities.

How to Disable Weak SSH Algorithms on RHEL 8/9/10

In our enterprise environment, we use Rapid7 InsightVM for continuous vulnerability management, and one persistent finding across multiple scan cycles has been the detection of weak SSH algorithms specifically CBC-mode ciphers, SHA-1 HMACs, and SHA-1–based key exchange methods. These flagged vulnerabilities remained despite explicitly configuring secure settings in /etc/ssh/sshd_config across our Red Hat systems (RHEL 7, 8, and 9).

Understanding SSH Cryptographic Components: HMACs, Ciphers, Kex, and MACs

Before we get into disabling weak SSH algorithms, it’s important to understand what these algorithms do. SSH security depends on several cryptographic components:

Key Exchange Algorithms (KEX)

Key Exchange (KEX) is the first step in setting up an SSH connection. It allows the client and server to securely agree on a shared secret key without ever sending the key over the network.

This secret is then used to create the encryption and authentication keys that protect the SSH session.

How does KEX work in SSH connection?

• Algorithm Negotiation: The SSH client and server each send a list of supported key exchange algorithms using the SSH_MSG_KEXINIT packet. The first mutually supported algorithm is selected.
• Key Exchange Process: For algorithms like Diffie-Hellman, the client and server exchange public values (e.g., e from the client and f from the server). Both sides compute the same shared secret K independently, using their private values and the peer’s public value.
• Server Authentication: The server generates a hash H from key exchange data and signs it using its host private key. The client verifies this signature using the server’s known public host key to confirm the server’s identity.
• Key Derivation: The shared secret K and the exchange hash H are used to derive session keys for encryption and message authentication.
• Rekeying (Optional): SSH can repeat the key exchange process during the session to limit the amount of data encrypted with a single key.

Common KEX Algorithms:

• diffie-hellman-group14-sha256: Uses 2048-bit DH group with SHA-256 (secure and recommended).
• curve25519-sha256: Elliptic Curve DH (ECDH) with Curve25519 and SHA-256 (fast and strong).
• ecdh-sha2-nistp256: ECDH with NIST P-256 curve and SHA-256.
• Legacy: diffie-hellman-group1-sha1 (1024-bit DH with SHA-1).

If you want to observe the key exchange process in action, just run this command in your terminal:

ssh -vvv username@your-ssh-server

Just look out for lines mentioning:

• SSH2_MSG_KEXINIT sent and received
• The proposed KEX algorithms
• The chosen key exchange algorithm (e.g., curve25519-sha256)
• SSH2_MSG_KEX_ECDH_REPLY
• SSH2_MSG_NEWKEYS

Ciphers (Encryption Algorithms)

Once the shared key is established, ciphers come into play. Ciphers are responsible for encrypting the data transferred between the SSH client and server, ensuring confidentiality.

So, after the client and server complete the key exchange (KEX) and agree on a shared secret key, that key is used to create encryption keys for the session.

Here’s what happens next:

1. Session keys are derived from the shared secret negotiated during KEX.
2. These session keys are used by the ciphers to encrypt and decrypt all data sent between the client and server.
3. Because ciphers are symmetric encryption algorithms, the same key encrypts and decrypts the data which keeps the communication confidential.
4. This means even if someone intercepts the network traffic, they cannot read the contents without the key.

In short, KEX securely creates the secret key, and ciphers use that key to lock and unlock the data you send over SSH.

Common Algorithms:

• aes256-ctr: AES-256 in Counter mode (secure, recommended).
• [email protected]: AES-128 with Galois/Counter Mode (GCM) for authenticated encryption.
• [email protected]: ChaCha20 stream cipher with Poly1305 authenticator (high-performance alternative to AES).
• Legacy: 3des-cbc (Triple DES in CBC mode), aes128-cbc (AES-128 in CBC mode).

Message Authentication Codes (MACs) and HMACs

MACs (Message Authentication Codes) ensure the integrity and authenticity of data sent over an SSH connection. They help verify that data hasn’t been tampered with during transit.

An HMAC (Hash-based MAC) is a common type of MAC that uses a cryptographic hash function (like SHA-1 or SHA-2) combined with a shared secret key.

How MACs Work in SSH:

• A MAC is calculated on each SSH packet before encryption. It covers:
  • The packet sequence number
  • The unencrypted payload
  • The shared secret
• This MAC is appended to the packet (either before or after encryption, depending on the algorithm).
• On the receiving side, the same calculation is performed and compared. If the MACs don’t match, the packet is rejected.
• SSH supports Encrypt-then-MAC (EtM) variants, where the MAC is calculated after encryption providing stronger protection against certain attacks.
• As defined in RFC 4253, the MAC is computed like this: MAC = HASH(key || sequence_number || packet_data)

Common MAC Algorithms in SSH:

• hmac-sha2-512 – HMAC; strong, uses SHA-512 (64-byte digest)
• [email protected] – UMAC (non-HMAC); very fast, 128-bit integrity
• [email protected] – AEAD (GCM mode); includes both encryption and MAC

Legacy / Weaker Algorithms:

• hmac-sha1 – HMAC; 20-byte digest, considered weak
• [email protected] – UMAC; 64-bit tag, less secure than 128-bit version
• hmac-md5 – HMAC; deprecated, insecure, avoid using

Sample SSH-related Vulnerability Reports

To illustrate the kind of issues we’ve encountered, here are some examples from our Rapid7 vulnerability reports:

SSH Weak Message Authentication Code (HMAC) Algorithms:

• Description: The SSH server supports cryptographically weak Hash-based Message Authentication Codes (HMACs), including MD5 or 96-bit hash-based algorithms. This is considered a security risk as these algorithms are more vulnerable to collisions and attacks.
• Recommendation: Disable any MD5 or 96-bit HMAC algorithms within the SSH configuration.
• CVSS Score: 7.5 (High)
• Vulnerability Proof: Running SSH service: Insecure MAC algorithms in use: hmac-sha1,[email protected],[email protected],[email protected]

SSH Server Supports 3DES Cipher Suite:

• Description: 3DES (Triple Data Encryption Standard) provides effective security of only 112 bits, which is now considered weak, particularly after the recommendations from ECRYPT II (2012) and various security bodies like BSI Germany and ANSSI France. While NIST still considers it suitable until 2030, it is advised to remove 3DES in favor of stronger ciphers for better long-term protection.
• Recommendation: Remove all 3DES ciphers from the cipher list specified in sshd_config.
• CVSS Score: 7.5 (High)
• Vulnerability Proof: Running SSH service. Insecure 3DES ciphers in use: 3des-cbc

This post documents how to properly disable these legacy SSH algorithms in RHEL 8/9/10 environments, aligning with Red Hat’s recommendations, ensuring compliance, and preventing recurring scanner false positives.

Verifying Weak SSH Algorithms in Use on RHEL Systems

Before diving into remediation, it’s important to verify whether the vulnerabilities, such as those flagged in the Rapid7 report, actually exist in your environment. In our case, while we didn’t find 3DES or MD5 algorithms in use, we did confirm that HMAC-SHA1 was still active, which was flagged as a weak algorithm.

To guide our review, here are some of the common weak SSH algorithms we are looking out for:

Weak MAC Algorithms

• hmac-sha1 – Vulnerable due to SHA-1 weaknesses
• hmac-md5 – Cryptographically broken
• hmac-md5-96 – Truncated MD5 (96-bit)
• hmac-sha1-96 – Truncated SHA-1 (96-bit)

Weak Cipher Algorithms

• 3des-cbc – Triple DES; limited key size, not secure by modern standards
• aes128-cbc, aes192-cbc, aes256-cbc – CBC mode is vulnerable to padding oracle attacks
• arcfour, arcfour128, arcfour256 – RC4 variants; known to be broken and insecure

Check Current SSH Server Configuration Options

First, examine what algorithms your SSH daemon is configured to use:

sudo sshd -T | grep -E "(macs|ciphers|kexalgorithms)"

Sample command output;

gssapikexalgorithms gss-group14-sha256-,gss-group16-sha512-,gss-nistp256-sha256-,gss-curve25519-sha256-,gss-group14-sha1-,gss-gex-sha1-
ciphers [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
macs [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
kexalgorithms curve25519-sha256,[email protected],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,diffie-hellman-group14-sha1

Based on this command output, we can confirm that weak HMAC algorithms are present in our SSH configuration, specifically hmac-sha1 and [email protected] appear in the MACs list, along with the weak key exchange algorithm diffie-hellman-group14-sha1. However, 3DES ciphers were not found as you can see there are no 3des-cbc or similar 3DES algorithms in our ciphers list, indicating this part of the Rapid7 report appears to be a false positive for our system.

Analyze SSH Connection Negotiations

To see what algorithms are negotiated during actual connections, you can try to ssh the server either locally or from another remote system, enabling debug on the connection.

RHEL 8.X:

ssh -vvv 192.168.233.249 2>&1 | grep -E "debug.*: (mac|cipher|kex)"

Sample command output;

debug2: KEX algorithms: sntrup761x25519-sha512,[email protected],curve25519-sha256,[email protected],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,ext-info-c,[email protected]
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: KEX algorithms: curve25519-sha256,[email protected],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,[email protected]
debug2: ciphers ctos: [email protected],[email protected],aes256-ctr,aes256-cbc,[email protected],aes128-ctr,aes128-cbc
debug2: ciphers stoc: [email protected],[email protected],aes256-ctr,aes256-cbc,[email protected],aes128-ctr,aes128-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha1,[email protected],hmac-sha2-512
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha1,[email protected],hmac-sha2-512
debug3: kex_choose_conf: will use strict KEX ordering
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [email protected] MAC:  compression: none
debug1: kex: client->server cipher: [email protected] MAC:  compression: none
debug1: kex_input_ext_info: server-sig-algs=
[email protected]'s password:

RHEL 9.X output:

debug2: KEX algorithms: sntrup761x25519-sha512,[email protected],curve25519-sha256,[email protected],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,ext-info-c,[email protected]
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: KEX algorithms: curve25519-sha256,[email protected],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,[email protected]
debug2: ciphers ctos: [email protected],[email protected],aes256-ctr,[email protected],aes128-ctr
debug2: ciphers stoc: [email protected],[email protected],aes256-ctr,[email protected],aes128-ctr
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha1,[email protected],hmac-sha2-512
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha1,[email protected],hmac-sha2-512
debug3: kex_choose_conf: will use strict KEX ordering
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [email protected] MAC:  compression: none
debug1: kex: client->server cipher: [email protected] MAC:  compression: none
debug1: kex_input_ext_info: server-sig-algs=
[email protected]'s password:

RHEL 10 SSH algorithm negotiation output:

debug2: KEX algorithms: sntrup761x25519-sha512,[email protected],curve25519-sha256,[email protected],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,ext-info-c,[email protected]
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: KEX algorithms: curve25519-sha256,[email protected],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,ext-info-s,[email protected]
debug2: ciphers ctos: [email protected],[email protected],aes256-ctr,[email protected],aes128-ctr
debug2: ciphers stoc: [email protected],[email protected],aes256-ctr,[email protected],aes128-ctr
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha1,[email protected],hmac-sha2-512
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha1,[email protected],hmac-sha2-512
debug3: kex_choose_conf: will use strict KEX ordering
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [email protected] MAC:  compression: none
debug1: kex: client->server cipher: [email protected] MAC:  compression: none
debug1: kex_input_ext_info: server-sig-algs=
debug1: kex_input_ext_info: [email protected]=<0>
debug1: kex_input_ext_info: [email protected] (unrecognised)
[email protected]'s password:

Based on the SSH connection debug output above, we can see the algorithm negotiation between client and server. The analysis shows:

Weak algorithms present on server (stoc – server to client):

• hmac-sha1, [email protected] – still visible on all RHEL versions
• [email protected], [email protected] – less common and considered weaker than 128-bit MACs
• diffie-hellman-group-exchange-sha1 and diffie-hellman-group14-sha1 in KEX algorithms only on RHEL 8
• aes256-cbc and aes128-cbc cipher modes (vulnerable to padding oracle attacks) only on RHEL 8.

Actually negotiated (secure):

• Key exchange: curve25519-sha256
• Encryption: [email protected]
• MAC: <implicit> (built into ChaCha20-Poly1305)

This demonstrates that while weak algorithms are available as fallback options, the SSH implementation correctly prioritizes secure modern algorithms when both client and server support them.

However, vulnerability scanners such as Rapid7 InsightVM may still flag these weak algorithms based on their presence, not their actual usage. For compliance and hardening purposes, these should be explicitly disabled.

Why SSH Remains Vulnerable Despite Hardening via sshd_config (RHEL 8/9/10)

You might have already hardened your SSH configuration by disabling weak algorithms directly in /etc/ssh/sshd_config. However, if you’re running RHEL 8, 9, or 10, those changes may not be taking effect and your system could still be using outdated or weak cryptographic algorithms, hence constant flags by Rapid7 scanner or any security scanner.

The reason?

After deeper investigation and cross-referencing with Red Hat’s official guidance, we identified the root cause: starting with RHEL 8, OpenSSH behavior is governed not just by sshd_config but also by system-wide crypto policies, which silently override manual configurations unless explicitly disabled or extended. Conversely, RHEL 7 does not use crypto policies at all, so sshd_config remains authoritative there.

RHEL 8 and newer versions enforce a global crypto policies that affects SSH configuration. As a result:

• No matter what ciphers, MACs, or key-exchange options you set in sshd_config, they will be ignored unless you explicitly disable or extend the system-wide crypto policy.
• The effective SSH configuration is defined by the files under /etc/crypto-policies/back-ends/, particularly opensshserver.config and openssh.config.

Because the reported vulnerabilities affect the SSH server (the sshd daemon), we will focus on reviewing the algorithms and settings defined in the SSH server’s crypto policy file, /etc/crypto-policies/back-ends/opensshserver.config. This file dictates which algorithms the server actually uses, so it’s the most relevant place to check and fix weak configurations.

So, what do the crypto-policy files tell us?

RHEL 8;

cat /etc/crypto-policies/back-ends/opensshserver.config

CRYPTO_POLICY='[email protected],[email protected],aes256-ctr,aes256-cbc,[email protected],aes128-ctr,aes128-cbc [email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha1,[email protected],hmac-sha2-512 -oGSSAPIKexAlgorithms=gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-,gss-gex-sha1-,gss-group14-sha1- -oKexAlgorithms=curve25519-sha256,[email protected],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 -oHostKeyAlgorithms=ecdsa-sha2-nistp256,[email protected],ecdsa-sha2-nistp384,[email protected],ecdsa-sha2-nistp521,[email protected],ssh-ed25519,[email protected],rsa-sha2-256,[email protected],rsa-sha2-512,[email protected],ssh-rsa,[email protected] -oPubkeyAcceptedKeyTypes=ecdsa-sha2-nistp256,[email protected],ecdsa-sha2-nistp384,[email protected],ecdsa-sha2-nistp521,[email protected],ssh-ed25519,[email protected],rsa-sha2-256,[email protected],rsa-sha2-512,[email protected],ssh-rsa,[email protected] -oCASignatureAlgorithms=ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-256,rsa-sha2-512,ssh-rsa'

From here, we can see:

• Weak Ciphers found: aes256-cbc and aes128-cbc are present, which are vulnerable to padding oracle attacks and should be removed.
• Weak MACs found: hmac-sha1 and [email protected] appear, which are vulnerable due to SHA-1 weaknesses. These should be deprecated in favor of stronger MAC algorithms (e.g., [email protected]).

RHEL 9/RHEL 10:

cat /etc/crypto-policies/back-ends/opensshserver.config

Ciphers [email protected],[email protected],aes256-ctr,[email protected],aes128-ctr
MACs [email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha1,[email protected],hmac-sha2-512
GSSAPIKexAlgorithms gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-
KexAlgorithms curve25519-sha256,[email protected],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
HostKeyAlgorithms ecdsa-sha2-nistp256,[email protected],[email protected],[email protected],ecdsa-sha2-nistp384,[email protected],ecdsa-sha2-nistp521,[email protected],ssh-ed25519,[email protected],[email protected],[email protected],rsa-sha2-256,[email protected],rsa-sha2-512,[email protected]
PubkeyAcceptedAlgorithms ecdsa-sha2-nistp256,[email protected],[email protected],[email protected],ecdsa-sha2-nistp384,[email protected],ecdsa-sha2-nistp521,[email protected],ssh-ed25519,[email protected],[email protected],[email protected],rsa-sha2-256,[email protected],rsa-sha2-512,[email protected]
CASignatureAlgorithms ecdsa-sha2-nistp256,[email protected],ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,[email protected],rsa-sha2-256,rsa-sha2-512
RequiredRSASize 2048

For RHEL 9 and 10, the policy files show similar patterns. While CBC ciphers are removed, the presence of hmac-sha1 and [email protected] remains a security concern.

Permanently Disable Weak SSH Algorithms on RHEL 8/9/10

As mentioned earlier, while you can harden your SSH server by defining strong ciphers, MACs, and KEX algorithms in sshd_config, this configuration can be silently overridden by Red Hat’s system-wide crypto policies starting from RHEL 8.

Therefore, to ensure weak cryptographic algorithms are actually disabled, it’s best practice to harden them at the crypto-policy level.

Red Hat provides four built-in crypto policy tiers:

• LEGACY: Maximum compatibility; allows insecure algorithms like SHA-1, MD5, and 3DES.
• DEFAULT: This is the default and current safe baseline; still permits some legacy options like hmac-sha1 and CBC-mode ciphers. DEFAULT is recommended for general use.
• FUTURE: More secure than DEFAULT; disables SHA-1, CBC ciphers, and enforces stricter key lengths (RSA/DH ≥ 3072 bits).
• FIPS: Federal Information Processing Standard (FIPS 140-2) compliance mode.
• CUSTOM: You can implement your own tailored configuration.

By default, RHEL 8, 9, and 10 systems use the DEFAULT policy:

sudo update-crypto-policies --show

DEFAULT

While DEFAULT is acceptable for many environments, it still allows weak algorithms, including hmac-sha1, hmac-sha1-etm, and even some CBC-mode ciphers (especially in RHEL 8). If your vulnerability reports have flagged these, you need to explicitly remove them from your crypto-policy setup.

So, how to disable such weak algorithms permanently?

Disable Weak Algorithms via Custom Crypto-Policy Module

Red Hat allows administrators to extend or modify system-wide cryptographic settings through the use of custom policy modules. These modules are simple text files that let you enable or disable specific cryptographic algorithms, tailored to your environment’s security requirements.

This modular approach offers a flexible way to harden cryptographic behavior without modifying the base policy directly, and it integrates cleanly with the system’s existing crypto-policies framework.

For example, if you need to disable weak SSH algorithms such as legacy ciphers and outdated MACs, you can create a custom module and apply it as part of a CUSTOM cryptographic policy.

Below is an example of a custom policy module (NO-WEAK-SSH-ALGOS.pmod) that removes several known-weak SSH ciphers and MACs:

Note: The name of the module, as well the Algorithms in the module file MUST be in upper case.

On RHEL 8 (currently using RHEL 8.10)

sudo tee << 'EOF' > /etc/crypto-policies/policies/modules/NO-WEAK-SSH-ALGOS.pmod
# Disable weak MAC algorithms
mac@SSH = -HMAC-SHA1

# Disable weak cipher algorithms
cipher@SSH = -AES-128-CBC -AES-256-CBC
EOF

On RHEL 9/RHEL 10:

sudo tee << 'EOF' > /etc/crypto-policies/policies/modules/NO-WEAK-SSH-ALGOS.pmod
# Disable weak MAC algorithms
mac@SSH = -HMAC-SHA1
EOF

If you want, you can create a separate module file for each algorithm.

Then apply the custom module. Instead of switching entirely to a CUSTOM policy, you can extend the currently active base policy (e.g., DEFAULT) by appending the module name:

sudo update-crypto-policies --set DEFAULT:NO-WEAK-SSH-ALGOS

This tells the system to use the DEFAULT policy with the modifications defined in your custom module.

You can then reboot the server to apply.

sudo reboot

However, if your custom crypto-policy module only targets SSH, then it’s enough to restart the SSH service:

sudo systemctl restart sshd

This ensures the SSH daemon picks up the updated cryptographic settings from the new policy.

To confirm your customizations are active:

update-crypto-policies --show

It must show the base policy alongside the custom module applied.

If you have a large number of servers affected by the same vulnerability, you can easily apply the suggested fix using Ansible. Below is a sample Ansible playbook you can use to automate the process and ensure all your systems are securely configured.

---
- name: Disable Weak SSH Algorithms on RHEL 8/9/10
  hosts: all
  become: yes
  vars:
    reboot: false  # Set to true if you are within maintenance window
    custom_policy_module: NO-WEAK-SSH-ALGOS 

  tasks:
    - name: Check current crypto policy
      command: update-crypto-policies --show
      register: crypto_policy
      changed_when: false

    - name: Show current policy (optional)
      debug:
        msg: "Current crypto policy is {{ crypto_policy.stdout }}"

    - name: Create crypto-policies module for RHEL 8
      copy:
        dest: /etc/crypto-policies/policies/modules/{{ custom_policy_module }}.pmod
        content: |
          # Disable weak MAC algorithms
          mac@SSH = -HMAC-SHA1

          # Disable weak cipher algorithms/add some if required
          cipher@SSH = -AES-128-CBC -AES-256-CBC
      when:
        - ansible_distribution_major_version == '8'
        - crypto_policy.stdout in ['DEFAULT', 'LEGACY']

    - name: Create crypto-policies module for RHEL 9/10
      copy:
        dest: /etc/crypto-policies/policies/modules/{{ custom_policy_module }}.pmod
        content: |
          # Disable weak MAC algorithms
          mac@SSH = -HMAC-SHA1
      when:
        - ansible_distribution_major_version in ['9', '10']
        - crypto_policy.stdout in ['DEFAULT', 'LEGACY']

    - name: Apply updated crypto policies
      command: update-crypto-policies --set DEFAULT:{{ custom_policy_module }}
      when: crypto_policy.stdout in ['DEFAULT', 'LEGACY']
      notify: "{{ 'Reboot the Server' if reboot else 'Restart sshd Service' }}"


    - name: Check final crypto policy
      command: update-crypto-policies --show
      register: final_crypto_policy
      changed_when: false

    - name: Show final policy (optional)
      debug:
        msg: "Final crypto policy is {{ final_crypto_policy.stdout }}"

  handlers:
    - name: Reboot the Server
      reboot:
        reboot_timeout: 600

    - name: Restart sshd Service
      service:
        name: sshd
        state: restarted

You can use Ansible AWX.

Enforce Modern Standards with the FUTURE Crypto Policy

While using the FUTURE cryptographic policy in RHEL 8+ raises the security bar significantly by enforcing the use of only modern and strong cryptographic standards, it can easily break compatibility with software, services, or devices that rely on older protocols or ciphers. FUTURE policy disables the following by default:

• TLS 1.0 and TLS 1.1
• RSA keys < 2048 bits
• SHA-1 signatures
• 3DES, RC4, MD5, and other legacy ciphers
• Weak DH groups
• Older SSH algorithms (e.g., SHA1 HMACs)
• …

Before adopting the FUTURE policy in production, it is strongly recommended to perform thorough testing in a controlled staging environment. This allows you to identify and resolve compatibility issues ahead of time.

Once you are ready to use it, you can simply apply the policy with:

sudo update-crypto-policies --set FUTURE

sudo reboot

Once the server boots, validate all your applications are working as expected.

If needed, you can revert to the DEFAULT policy.

Validate That Weak SSH Algorithms Are Disabled

After applying crypto-policy changes or customizing your SSH configuration, it’s essential to confirm that the weak algorithms are no longer accepted by the server. Without proper validation, vulnerable settings may silently persist, especially if policy modules or defaults were not applied as intended.

Here are a few reliable ways to validate the SSH server configuration:

Rescan the Server with a Vulnerability Scanner

If your original report came from a security scanner (like Rapid7, Qualys, or Nessus), re-running the scan is the most direct way to confirm remediation. Ensure the scan targets the correct port and SSH service.

Enumerate SSH Algorithms using NMAP

nmap is a powerful network scanning tool that can also be used to enumerate the SSH algorithms supported by a server using the ssh2-enum-algos script. This helps identify weak or outdated cryptographic configurations.

Assuming you are authorized to scan the target system, you can run the following command replacing the IP address with your RHEL host’s IP:

nmap --script ssh2-enum-algos -sV -Pn -p 22 <your-rhel-ip>

This will list supported key exchange algorithms, ciphers, MACs, and more.

Here is a sample SSH algorithms enumeration output on RHEL 8.10 server:

Starting Nmap 7.93 ( https://nmap.org ) at 2025-08-25 23:38 CEST
Nmap scan report for 192.168.233.249
Host is up (0.0010s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.0 (protocol 2.0)
| ssh2-enum-algos: 
|   kex_algorithms: (12)
|       curve25519-sha256
|       [email protected]
|       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
|       [email protected]
|   server_host_key_algorithms: (5)
|       rsa-sha2-512
|       rsa-sha2-256
|       ssh-rsa
|       ecdsa-sha2-nistp256
|       ssh-ed25519
|   encryption_algorithms: (5)
|       [email protected]
|       [email protected]
|       aes256-ctr
|       [email protected]
|       aes128-ctr
|   mac_algorithms: (6)
|       [email protected]
|       [email protected]
|       [email protected]
|       hmac-sha2-256
|       [email protected]
|       hmac-sha2-512
|   compression_algorithms: (2)
|       none
|_      [email protected]

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 5.74 seconds

Based on the Nmap command output:

• Encryption (Ciphers): The SSH server supports strong, modern ciphers such as chacha20-poly1305, aes256-gcm, and aes128-gcm. These ciphers provide both encryption and integrity (AEAD). It also supports aes256-ctr and aes128-ctr, which are secure but do not have built-in integrity protection. There are no weak or outdated ciphers enabled.
• MAC Algorithms: Only secure encrypt-then-MAC (EtM) variants are used, including hmac-sha2-256-etm, hmac-sha2-512-etm, and umac-128-etm. These MACs offer strong message integrity and are recommended. Deprecated MACs like hmac-md5 or hmac-sha1 are not present.

Use the ssh-audit Tool

ssh-audit is a purpose-built tool for analyzing SSH server configurations. It reports supported algorithms, server banner info, and flags weak or deprecated settings.

You can install it on your bastion host:

pip3 install ssh-audit

Then audit your SSH server:

.local/bin/ssh-audit 10.184.10.62

Carefully examine the full output, check every section including key exchange, encryption ciphers, MACs, and host keys. Look out for anything marked as weak, deprecated, or vulnerable.

Conclusion

Disabling weak SSH algorithms on RHEL 8/9/10 is essential to strengthen your system’s security by eliminating outdated and vulnerable cryptographic methods. Using tools like ssh-audit, Nmap, Vulnerability scanners can allow you to enforce modern standards effectively.

For more details, see the crypto-policies manual with man crypto-policies.