Disable Weak SSHD Algorithms

What the weak SSH algorithm hardener does

This Automox Worklet™ writes a strict cryptographic allowlist into /etc/ssh/sshd_config and restarts the sshd service so OpenSSH stops negotiating weak primitives. The Worklet appends three directives – Ciphers, KexAlgorithms, and MACs – that name only modern AEAD and ETM constructions. Subsequent connections must select an algorithm from this list, and the legacy options that ship enabled on most distributions stop being offered to clients.

The evaluation phase runs sshd -T and greps the active configuration for the regex sha1|rc4|arcfour|md5|blowfish|idea|3des|cast128|cbc against the ciphers, macs, and kexalgorithms lines. Any match flags the endpoint as non-compliant. The remediation phase then appends the allowlist and runs service sshd restart so the new configuration takes effect on the next inbound session.

The Worklet does not delete or comment out existing lines. It appends the new directives to the end of sshd_config, and OpenSSH honors the first obtained value for each keyword per sshd_config(5). On a stock distribution that ships sshd_config without explicit Ciphers, MACs, or KexAlgorithms lines, the appended values become the first match and take effect immediately. If your hosts already define one of these keywords earlier in the file, edit that line in place or remove it before running this Worklet so the appended allowlist wins.

Why disable weak SSH algorithms

Vulnerability scanners flag weak SSH algorithms on almost every default Linux install. CIS Benchmarks 5.2.13, 5.2.14, and 5.2.15 require explicit Ciphers, MACs, and KexAlgorithms allowlists. NIST 800-53 controls SC-8 and SC-13 demand approved cryptography for transmitted authenticator and session data. PCI-DSS Requirement 4 calls out strong cryptography for any system handling cardholder data, and SOC 2 Common Criteria 6.7 leans on the same control. The concrete attack surface is well documented. 3DES and RC4 have practical key-recovery and biased-keystream weaknesses. CBC-mode ciphers without ETM are vulnerable to plaintext-recovery and prefix-truncation attacks. SHA1-based MACs are subject to collision and length-extension concerns. None of these belong on an internet-reachable sshd in 2026.

This Worklet writes explicit Ciphers, MACs, and KexAlgorithms allowlists to /etc/ssh/sshd_config on every Linux endpoint in scope, then reloads sshd so the next handshake refuses 3DES, RC4, CBC-mode without ETM, and SHA1-HMAC suites. Bare-metal servers, container hosts, and developer workstations all converge on the same configuration, and the CIS 5.2.13, 5.2.14, and 5.2.15 controls produce deterministic per-host evidence that maps directly to the scanner finding.

How SSH algorithm hardening works

1. Evaluation phase: The script runs sshd -T to dump the resolved daemon configuration, including any defaults the binary inherits when sshd_config does not name a value. It pipes that output through grep for the ciphers, macs, and kexalgorithms lines, then through a second grep for the weak-algorithm pattern (sha1, rc4, arcfour, md5, blowfish, idea, 3des, cast128, cbc). If grep returns 0 (a match was found), the script exits 1 to mark the endpoint non-compliant and trigger remediation. If no match is found, it exits 0 and the policy run reports compliant.

2. Remediation phase: The script appends three lines to /etc/ssh/sshd_config using a heredoc. Ciphers is set to chacha20-poly1305@openssh.com, aes256-gcm@openssh.com, aes128-gcm@openssh.com, aes256-ctr, aes192-ctr, aes128-ctr. KexAlgorithms is set to curve25519-sha256@libssh.org, diffie-hellman-group-exchange-sha256. MACs is set to 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. The script then runs service sshd restart so the new configuration is loaded by the listening daemon.

SSH hardening requirements

• Linux endpoint with OpenSSH server installed and the sshd service managed by SysV init, systemd, or a compatible service manager that accepts service sshd restart

• OpenSSH 6.5 or later for full support of chacha20-poly1305, curve25519-sha256, and the ETM MAC variants (most supported distributions ship 7.x or newer)

• Root privileges for the Automox agent (the default agent context already meets this)

• Inventory of SSH client versions in your environment; very old clients (OpenSSH < 6.5, PuTTY < 0.68, legacy Java SSH libraries) may fail to negotiate against the new allowlist

• Originally validated on Ubuntu 18.04; the directives are portable to RHEL, CentOS, Rocky, Alma, Debian, and modern Ubuntu releases that ship OpenSSH 6.5+

• Out-of-band recovery path (console, IPMI, cloud serial console) in case a remote host loses SSH access during testing

• No pre-existing Ciphers, MACs, or KexAlgorithms lines earlier in /etc/ssh/sshd_config; OpenSSH uses the first obtained value for each keyword, so an existing line earlier in the file overrides the appended allowlist

Expected sshd state after remediation

After the Worklet runs, sshd offers only the algorithms in the allowlist. Validate from the endpoint with sshd -T | grep -E '^(ciphers|macs|kexalgorithms)' and confirm that none of sha1, rc4, arcfour, md5, blowfish, idea, 3des, cast128, or cbc appears in the output. From a remote workstation, you can probe the live daemon with ssh -oCiphers=arcfour user@host. The connection should fail with no matching cipher found. For a broader view, run a passive scan with nmap -p 22 --script ssh2-enum-algos against the host and check the reported algorithm lists.

Modern OpenSSH, OpenSSH-for-Windows, PuTTY 0.68+, WinSCP, and the Go and Python ssh libraries all negotiate against this allowlist without changes. Very old clients fail to connect, which is the point – those clients were the reason the weak algorithms were enabled in the first place. The configuration persists across sshd restarts and system reboots because the directives live in /etc/ssh/sshd_config. The next evaluation run finds no weak algorithm in sshd -T output and reports the endpoint compliant without applying remediation again. For audit evidence, capture the relevant lines of /etc/ssh/sshd_config and the sshd -T output alongside the Automox policy run identifier.