Welcome to HowToShipIt — practical how-to guides for developers: code, AI tools, and servers, explained step by step.

OpenSSH 10.6 upgrade checklist: server rack with padlock and key-exchange motifs

OpenSSH 10.6 Upgrade Checklist: What Breaks and What to Do About It (2026)

by

OpenSSH 10.6 landed on October 6, 2026, and unlike most point releases, this one can break things on your servers. It disables part of SSH compression to close a plaintext-recovery side channel, refuses certain usernames on the command line, enables a post-quantum signature algorithm that invalidates older experimental keys, and starts deprecating scp -R. It also adds a new log line that will tell you which of your clients are still using weak cryptography.

This post is the upgrade checklist: what changed, what can break, and the exact commands to audit your fleet before the packages land. It is dated October 10, 2026 — four days after release, which means rolling distros already have it and the stable ones are close behind.

What OpenSSH 10.6 actually changes

The release notes frame 10.6 as a security-hardening release, and that is fair. The headline items:

  • The LZ77 dictionary coder is disabled in both ssh and sshd, making the Compression option noticeably weaker (details below).
  • ssh now refuses command-line usernames containing $ or \, closing a shell-injection vector through ProxyCommand and Match exec.
  • The hybrid post-quantum signature algorithm ssh-mldsa44-ed25519 (ML-DSA-44 combined with Ed25519) is enabled. Keys made with the older experimental version must be regenerated or removed.
  • sshd gains WarnWeakCrypto, enabled by default, which logs connections that negotiate a key exchange the project does not consider post-quantum safe.
  • scp -R (remote-to-remote copy) begins deprecation: it still works, but now prints a warning, and a future release will ignore the flag.
  • The team says it will ship releases more frequently “for now,” citing the surge in AI-assisted vulnerability reports.

The two changes that can break things

1. LZ77 dictionary coding is gone — SSH compression got weaker

This is the big one, and the security reasoning is sound. A paper titled Crossing the Streams by Fabian Bäumer and Marcus Brinkmann (Ruhr University Bochum) showed that SSH’s shared compression context across multiplexed channels is a length oracle: an attacker who can feed chosen input into one channel (say, a port forward) and observe encrypted traffic lengths can recover secrets moving through another channel (say, your interactive shell). In their lowest-noise tests they recovered an eight-character secret in a median of 276 guesses across 100 trials.

LZ77 works by replacing repeated strings with back-references into a shared buffer. That back-reference is what makes compressed length depend on cross-channel buffer contents. OpenSSH 10.6 disables the dictionary coder while leaving the entropy-coding stage functional — compression still runs, it just compresses less. The release notes explicitly recommend application-level compression instead, which they say is typically more effective and immune to this class of attack.

One important caveat: OpenSSH ships with compression off by default, so this only affects sessions where you explicitly set Compression yes or pass -C. If you do lean on it for bandwidth-starved multiplexed sessions, budget for smaller ratios — or move compression up to the application (e.g. rsync --compress, which compresses before the SSH transport).

Audit it:

# Client-side: your config and any -C flags
grep -rn 'Compression' /etc/ssh/ssh_config /etc/ssh/ssh_config.d/ ~/.ssh/config 2>/dev/null
grep -rn 'ssh -C' ~/bin /usr/local/bin 2>/dev/null

# Server-side: who enables it on your fleet
grep -rn 'Compression' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/ 2>/dev/null

If you find Compression yes anywhere, test what the reduced ratio means for that workload after upgrading — do not just assume it is fine.

2. Usernames with $ or \ are refused on the command line

Running ssh user$@host or ssh 'domain\user'@host now fails outright. The point is to stop a username supplied from an untrusted source from injecting into a shell context through ProxyCommand or Match exec. Usernames set with the User directive in config files are exempt, and the maintainers are upfront that a mitigation like this cannot be absolute — it closes one vector, not the whole class.

Audit it: search your automation for any place a username flows from a variable into an ssh command line — provisioning scripts, CI jobs, jump-host wrappers. If any username can contain $ or a backslash (Windows-style DOMAIN\user formats are the classic case), those invocations will start failing the moment the client upgrades.

Three things to act on, not just note

1. Regenerate experimental post-quantum keys

The hybrid ssh-mldsa44-ed25519 signature algorithm went from experimental in 10.4 to enabled in 10.6 — and the @openssh.com vendor suffix is gone. If you generated test keys with the experimental implementation (around July), those keys will not work. Find and replace them:

# Find experimental keys (public and private)
grep -rl 'mldsa44-ed25519@openssh.com' ~/.ssh/ /etc/ssh/ 2>/dev/null

# Generate a fresh post-quantum hybrid key
ssh-keygen -t ssh-mldsa44-ed25519 -C "pq-key $(date +%F)" -f ~/.ssh/id_pq

# Install it where it belongs, then remove the old key files
ssh-copy-id -i ~/.ssh/id_pq.pub user@host

While you are in there: the default KDF rounds for new passphrase-protected private keys went from 24 to 32. That only applies to keys you create from now on; existing keys are untouched.

2. Hunt down scp -R before it stops working

scp -R does remote-to-remote copies by shelling out on a host — a fragile optimisation with quoting risks, per the release discussion. In 10.6 it warns; in a future release the flag will be silently ignored. Grep your scripts now, because “silently ignored” in a future release means transfers that just… do not happen.

# Find scp -R usage in your scripts
grep -rn 'scp.*-R' ~/bin /usr/local/bin /opt/scripts 2>/dev/null

The replacement depends on the workflow: stage through the local machine (scp host1:path /tmp && scp /tmp host2:path), or switch the transfer to rsync -e ssh, which handles remote-to-remote via the local host by default.

3. Let WarnWeakCrypto build your client-upgrade list

On the server side, WarnWeakCrypto is now on by default in sshd (it was previously client-only). Every connection that negotiates a key exchange OpenSSH does not consider post-quantum safe gets logged. That is effectively a free inventory of which clients, bots, and automation still need upgrading ahead of harvest-now-decrypt-later concerns.

# Confirm the effective setting after upgrading
sudo sshd -T | grep -i warnweakcrypto

# Then watch your auth logs over the next week for the new warnings
sudo journalctl -u sshd --since '7 days ago' | grep -i -E 'weak|crypto'

If the noise bothers you, the option is configurable in sshd_config — but run it on for a week first and use the output as your upgrade list.

The upgrade checklist, step by step

In order, the way you would actually do it on a Friday with coffee:

  1. See what you are running. ssh -V on clients; on servers, apt policy openssh-server (Debian/Ubuntu), pacman -Q openssh (Arch), dnf list installed openssh (Fedora/RHEL).
  2. Check whether 10.6 has reached your distro yet. Rolling distros moved fast — Arch-based systems shipped 10.6p1 within hours of the October 6 release. Debian has openssh-server_10.6p1-1 in sid and the package tracker shows the maintainer actively packaging 10.6 between October 7 and 9, so stable follows distro policy. On Ubuntu and RHEL-likes, check your package manager rather than assuming. Do not compile from source on a production box unless you have a real reason.
  3. Open a spare session before you touch sshd. This advice never expires: keep one working SSH connection open while you upgrade and restart, so a config mistake cannot lock you out of your own VPS. If your VPS has no recent backup, fix that first with this automated VPS backups setup.
  4. Upgrade, test the config, restart. sudo sshd -t validates the config before you commit. Restart with sudo systemctl restart sshd, then open a new connection from your spare terminal to prove it works before closing anything. If this is a brand-new box, start with setting up a VPS from scratch.
  5. Run the compression audit from the section above. If anything relies on Compression yes, decide now whether to accept weaker ratios or move compression to the application.
  6. Run the username audit. Any script building ssh command lines from untrusted input needs a look, especially DOMAIN\user formats.
  7. Regenerate experimental PQ keys and replace scp -R in scripts.
  8. Check your SFTP workflows still behave. 10.6 tightens SFTP path validation so a malicious server cannot trick recursive copies into writing outside the destination directory (good news), and mkdir in the sftp client now supports -p — you can drop workarounds that created directory trees one level at a time.
  9. Watch the logs for a week. The WarnWeakCrypto entries are your punch list for client upgrades.

Also in 10.6, worth knowing

  • ChannelTimeout now accepts fractional seconds, and there are broader TCP keepalive handling improvements.
  • ssh-add gets a -P flag for security tokens that do not need a PIN; FIDO resident keys now respect their credential-protection policy.
  • ssh-keygen can dump keys in hexdump form.
  • Servers can count “key ok” probes separately from failed logins via the new PubkeyOptions max-pk-ok option, so clients can offer more keys before getting kicked off.
  • Several server-side corrections: maximum packet lengths are enforced after decompression, the authorized_keys restriction is now correctly applied to tunnel forwarding, and a daylight-saving-time conversion that could produce wrong certificate expiry times is fixed.
  • On legacy platforms that require root for PTY allocation without file-descriptor passing (SCO OpenServer 5, QNX 6), sshd now forces GatewayPorts and StreamLocalForwarding off — full support is slated for removal.
  • On macOS, sshd sandboxing is no longer supported on OS X SDK 27 and later, because Apple removed the API OpenSSH relied on.
  • Windows admins: Microsoft ships its own port of OpenSSH as a Windows optional feature and had not said when 10.6 reaches it at the time of writing — check ssh -V on your Windows hosts instead of assuming.

The bigger story: expect SSH updates more often

The release notes say the OpenSSH team received a large number of security reports recently, many of them findings from AI models or made with AI assistance — and that in several cases a different researcher independently found the same bug later, which suggests adversaries could too. Two of the 10.6 fixes credit Chris Rohlf working with Claude and Anthropic Research. The upshot: the team will, “for now,” ship releases more frequently instead of batching fixes into the next planned release.

For you, that means SSH joins the list of packages worth updating on a short cycle rather than quarterly. Pin a reminder to check the official release notes page monthly — with this cadence, 10.7 will not wait for you.

Further Reading & References

Related Posts:

Leave a Comment