Articles

Harden sshd_config: Disable Weak Ciphers and Options (2026)

April 6, 2026 7 min read

SSH is surprisingly vulnerable to certain types of attacks if not configured carefully, and disabling weak ciphers and options is a crucial step in hardening your sshd_config.

Here’s how to lock down your SSH server by disabling outdated and insecure cryptographic algorithms and configurations:

Disabling Weak Ciphers

SSH ciphers are the algorithms used to encrypt the data transmitted between the client and the server. Older ciphers are often susceptible to brute-force attacks or have known vulnerabilities.

Diagnosis: Check your current sshd_config for the Ciphers directive. If it’s not present, the system is using its default list, which may include weak ciphers.

grep Ciphers /etc/ssh/sshd_config

Common Causes & Fixes:

  1. aes128-cbc and aes192-cbc: These are older CBC mode ciphers. While not immediately broken, they are slower and less secure than modern GCM modes.

    • Diagnosis: Your Ciphers line might look like this: Ciphers aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc.
    • Fix: Remove aes128-cbc and aes192-cbc from the Ciphers list.
    • Why it works: By removing these, you force clients to use stronger, more modern encryption algorithms.
    • Example Ciphers line: Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

  2. 3des-cbc: This cipher is very old and significantly weaker than modern alternatives. It’s also notoriously slow.

    • Diagnosis: Look for 3des-cbc in your Ciphers directive.
    • Fix: Remove 3des-cbc.
    • Why it works: Eliminates a known weak cipher, improving both security and performance.
    • Example Ciphers line (after removing 3des-cbc): Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

  3. blowfish-cbc: Blowfish is another older cipher with known weaknesses and is generally not recommended.

    • Diagnosis: Check for blowfish-cbc in your Ciphers.
    • Fix: Remove blowfish-cbc.
    • Why it works: Disables a cipher that has fallen out of favor due to security concerns.
    • Example Ciphers line (after removing blowfish-cbc): Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

  4. CBC Mode Ciphers in General: While specific ciphers like aes128-cbc are weak, the CBC mode itself can be vulnerable to padding oracle attacks if not implemented perfectly. Modern GCM (Galois/Counter Mode) and CTR (Counter Mode) ciphers are generally preferred.

    • Diagnosis: Your Ciphers line includes many entries ending in -cbc.
    • Fix: Prioritize and exclusively use GCM and CTR mode ciphers. A good modern Ciphers directive is: Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr.
    • Why it works: GCM and CTR modes are authenticated encryption modes that provide both confidentiality and integrity, and are generally considered more robust and performant than CBC modes.

Disabling Weak MACs (Message Authentication Codes)

MACs are used to verify the integrity of the data transmitted. Weak MACs can be vulnerable to forgery.

Diagnosis: Check your sshd_config for the MACs directive.

grep MACs /etc/ssh/sshd_config

Common Causes & Fixes:

  1. hmac-md5 and hmac-sha1: MD5 is cryptographically broken, and SHA1 has known collision vulnerabilities, making them unsuitable for secure MACs.

    • Diagnosis: Your MACs line might contain hmac-md5 or hmac-sha1.
    • Fix: Remove hmac-md5 and hmac-sha1 from the MACs list.
    • Why it works: Eliminates known weak hashing algorithms used for message integrity checks.
    • Example MACs line: MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

  2. umac-32@openssh.com: This is a less secure variant of UMAC.

    • Diagnosis: Look for umac-32@openssh.com in your MACs.
    • Fix: Remove umac-32@openssh.com.
    • Why it works: Disables a weaker MAC algorithm.
    • Example MACs line (after removing umac-32@openssh.com): MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

Disabling Weak Key Exchange Algorithms

Key exchange algorithms are used to establish the shared secret key for the SSH session. Weak algorithms can be vulnerable to man-in-the-middle attacks.

Diagnosis: Check your sshd_config for the KexAlgorithms directive.

grep KexAlgorithms /etc/ssh/sshd_config

Common Causes & Fixes:

  1. diffie-hellman-group-exchange-sha1 and diffie-hellman-group1-sha1: These older Diffie-Hellman methods use SHA1, which is no longer considered secure for key exchange.

    • Diagnosis: Your KexAlgorithms line contains diffie-hellman-group-exchange-sha1 or diffie-hellman-group1-sha1.
    • Fix: Remove these from the KexAlgorithms list.
    • Why it works: Prevents the use of weak key exchange methods that rely on compromised hashing algorithms.
    • Example KexAlgorithms line: KexAlgorithms curve25519-sha256,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

  2. Weak Diffie-Hellman Groups: Even with stronger algorithms, using Diffie-Hellman groups with insufficient bit lengths can be problematic.

    • Diagnosis: If you’re using diffie-hellman-group-exchange-sha256, ensure your server is configured to favor larger groups.
    • Fix: Explicitly set the minimum DH group size. Add GSSAPIKexAlgorithms and KexAlgorithms to include modern, strong options like curve25519-sha256. For older systems, you might need to generate a strong DH group.
    • Why it works: Ensures that the ephemeral keys generated during the key exchange are large enough to resist computational attacks.
    • Example KexAlgorithms line: KexAlgorithms curve25519-sha256,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

Disabling Legacy Options

Beyond cryptographic algorithms, certain SSH options can weaken security.

Diagnosis: Check your sshd_config for directives like Protocol, PermitRootLogin, PasswordAuthentication, and UsePAM.

grep Protocol /etc/ssh/sshd_config
grep PermitRootLogin /etc/ssh/sshd_config
grep PasswordAuthentication /etc/ssh/sshd_config
grep UsePAM /etc/ssh/sshd_config

Common Causes & Fixes:

  1. Protocol 1: SSHv1 is obsolete, insecure, and has been completely removed from modern OpenSSH versions.

    • Diagnosis: You might see Protocol 2,1 or just Protocol 1.
    • Fix: Ensure Protocol 2 is set. If the line is commented out, it defaults to Protocol 2.
    • Why it works: Enforces the use of the secure SSHv2 protocol.
    • Example Protocol line: Protocol 2

  2. PermitRootLogin prohibit-password or PermitRootLogin yes: Allowing direct root login, especially with passwords, is a significant security risk.

    • Diagnosis: Check the value of PermitRootLogin.
    • Fix: Set PermitRootLogin no or, if absolutely necessary for specific workflows, PermitRootLogin prohibit-password (and ensure you use key-based authentication for root). The most secure is no.
    • Why it works: Prevents direct brute-force attacks against the root account. Users should log in as a regular user and then su or sudo to root.
    • Example PermitRootLogin line: PermitRootLogin no

  3. PasswordAuthentication yes: While convenient, password authentication is susceptible to brute-force attacks. Key-based authentication is significantly more secure.

    • Diagnosis: Check the value of PasswordAuthentication.
    • Fix: Set PasswordAuthentication no. Ensure you have key-based authentication set up and tested before disabling password auth.
    • Why it works: Eliminates the possibility of attackers guessing or brute-forcing user passwords.
    • Example PasswordAuthentication line: PasswordAuthentication no

  4. UsePAM yes (with weak PAM configurations): PAM (Pluggable Authentication Modules) is powerful but can be misconfigured, negating other SSH security measures.

    • Diagnosis: Check UsePAM. If yes, examine your PAM configuration files (e.g., /etc/pam.d/sshd) for any weak settings.
    • Fix: If you don’t strictly need PAM for SSH (e.g., for complex account management or MFA integration that you haven’t specifically set up), consider setting UsePAM no. If you do need PAM, ensure it’s configured with strong authentication methods.
    • Why it works: Prevents potentially insecure authentication flows managed by PAM from undermining SSH’s own security settings.
    • Example UsePAM line: UsePAM no (or a carefully secured UsePAM yes)

After making these changes, remember to restart the SSH service for them to take effect:

sudo systemctl restart sshd
# or
sudo service ssh restart

The next problem you’ll likely encounter is clients that cannot connect because they don’t support the new, strict cipher/MAC/Kex settings.

More Deep Dives in Ssh

Want structured learning?

Take the full Ssh course →