SSH ciphers, key exchange and MACs

The fix/etc/ssh/sshd_config

# Subtract what you must; do not replace the list.
Ciphers -*-cbc
MACs -*-96,hmac-sha1*

On a current OpenSSH, doing nothing is also a valid answer. Read on before applying anything here.

Why it matters — and why the usual advice is backwards

This is the control most likely to be applied from a copied snippet, and the one where a copied snippet does the most damage.

OpenSSH ships strong defaults and has for years. Weak algorithms are removed from the defaults as they age out: CBC ciphers, arcfour, and SHA-1 key exchange are already gone from the default set on any supported version. There is very little left for a hand-written list to remove.

Meanwhile the defaults keep improving. OpenSSH 10.0 made mlkem768x25519-sha256 the default key exchange — a hybrid post-quantum algorithm intended to resist an attacker who records traffic now and decrypts it after a quantum computer exists. OpenSSH 9.9 introduced it, alongside sntrup761x25519-sha512 which had already been enabled by default earlier.

Now consider what happens when you paste a KexAlgorithms line from a 2018 hardening post. It lists curve25519-sha256 and friends — all fine algorithms — and by replacing the default list rather than editing it, it silently excludes the post-quantum exchange your OpenSSH would otherwise have negotiated. The config looks hardened. It has, in the only way that matters here, made the host weaker than leaving it alone.

That’s the real exposure this page closes: not weak defaults, but confident snippets that override good ones.

If you must restrict, subtract — don’t replace

OpenSSH supports modifying the default list instead of overwriting it:

Syntax	Meaning
-	Remove these from the default list
+	Append these to the end of the default list
^	Move these to the head of the default list
(no prefix)	Replace the list entirely — this is the dangerous one

So Ciphers -*-cbc removes any CBC cipher that might exist while leaving everything else — including future additions from upgrades — intact. A bare Ciphers aes256-gcm@openssh.com,... freezes your host at the moment the line was written.

Ask what a policy actually requires. “No CBC” is a subtraction. “Only these four algorithms” is a replacement, and it needs revisiting at every upgrade.

See what your build actually supports

ssh -Q kex        # key exchange algorithms
ssh -Q cipher     # ciphers
ssh -Q mac        # MACs

Verify it worked

Check the effective lists on the running daemon:

sudo sshd -T | grep -iE '^(ciphers|kexalgorithms|macs) '

On OpenSSH 10.x with defaults, kexalgorithms should begin with mlkem768x25519-sha256. If it doesn’t, something in your config replaced the default list — that is the thing to fix.

Confirm what a real connection negotiates, rather than what is offered:

ssh -v youruser@host 'true' 2>&1 | grep -i 'kex: algorithm\|cipher:'

Before you apply this

Restricting algorithms is how you lock out clients, not yourself — your own session already negotiated successfully and is unaffected.

The breakage lands on everything else that connects: CI runners, backup agents, monitoring, git deploy keys, network appliances, and any older client. A subtraction rarely breaks them; a replacement often does.

Before applying a replacement list, connect from your oldest client and from your automation, not just your laptop. And be aware sshd -T validates syntax but cannot tell you which of your clients can still negotiate.

Related

• Choose the right SSH key type — key algorithms, as distinct from transport algorithms.