OpenSSH 10.6 ships quantum-safe signatures and kills a nasty compression side channel — plus a frank admission from the team: AI is finding the bugs now, so releases will come faster.

OpenSSH 10.6 landed on October 6, and for once a point release is worth reading the release notes for. The headline is a hybrid post-quantum signature algorithm, but the story hiding underneath is bigger: the OpenSSH team says AI-assisted bug hunting has changed how it ships software.

Quantum-Safe SSH Is Finally Here

The headline feature is ssh-mldsa44-ed25519, a hybrid signature algorithm that pairs the NIST-standardized ML-DSA-44 lattice scheme with the familiar Ed25519. The hybrid design means a break in either algorithm alone doesn't sink your connection — belt and suspenders, for a threat model where quantum computers capable of running Shor's algorithm at scale may one day arrive.

One catch, and it bites: earlier experimental post-quantum keys used an @openssh.com vendor suffix. The 10.6 algorithm drops the suffix, which means keys generated with the experimental scheme must be regenerated or removed — they won't interoperate. If you experimented with PQ keys in a lab or on a staging fleet, plan a key rotation, not just a package upgrade.

Equally interesting is WarnWeakCrypto arriving in sshd_config. The option existed on the client side; now the server can enable it too (it's on by default) and will log when a client negotiates a key agreement scheme that isn't post-quantum safe. That's the first built-in telemetry OpenSSH gives operators about how much of their traffic is still classically protected — worth a look at your logs a week after rollout.

The Compression Side Channel That Cost You -C

The sharper edge of this release sits in the Security section. Researchers Fabian Bäumer and Marcus Brinkmann described "Crossing the Streams" — a chosen-plaintext attack that exploits the shared LZ77 compression dictionary across multiplexed SSH channels to recover secrets from one channel by interacting with another.

OpenSSH's answer is blunt: disable the LZ77 dictionary coder entirely. It kills the attack, but compression becomes noticeably less effective — the release notes admit it outright. The recommendation is to stop leaning on SSH's own compression and move to application-level compression instead, which is both more effective and immune to this attack class. If your rsync-over-SSH jobs have been living on -C, this is the release that tells you to move the compression up the stack.

The security fixes don't stop there:

  • Command-line usernames get strict. $ and \ are now rejected in usernames typed on the command line, closing an injection path where untrusted usernames could escape into ProxyCommand, Match exec, and friends. Usernames in config files aren't affected — this targets the case where SSH's command line is exposed to input you don't fully trust.
  • sftp validates server paths. Recursive copies can no longer be tricked by a malicious server into writing outside the target directory.
  • GSSAPI credential hygiene. Credentials from a failed GSSAPI attempt no longer linger where a later successful one could pick them up.
  • The restrict keyword is finally honored for tunnel forwarding in authorized_keys, and sshd processes that retained root privilege on exotic platforms lose the GatewayPorts/StreamLocalForwarding escape hatches.

Why This Release Matters Beyond the Changelog

Read the release notes' introduction and you'll find the most honest paragraph in open-source security this month: the OpenSSH team has been flooded with security reports, many from AI models or with AI assistance. And they've seen cases where an AI-found bug was independently rediscovered by a different researcher — which means adversaries who never report anything can likely find these bugs too.

Their response is a policy change, not a patch: more frequent releases to get fixes into users' hands faster, instead of batching them into the next planned release. OpenSSH 10.6 is the first fruit of that cadence, and if the team holds to it, your SSH fleet will need a tighter patching rhythm. Keep your update automation honest — unattended-upgrade style tooling, a staging host that gets new packages first, and a rollback plan.

Your 10.6 Upgrade Checklist

  1. Check the WarnWeakCrypto logs a few days after upgrading your bastions and jump hosts. You'll see exactly how much of your client population still negotiates classically.
  2. Rotate experimental PQ keys. If you generated ML-DSA keys with the old @openssh.com suffix, regenerate them — 10.6 won't use the old form.
  3. Expect the scp -R warning. The remote-to-remote -R flag starts its deprecation now; it still works, but stderr will tell you its days are numbered. It will be ignored entirely in a future release.
  4. Benchmark your -C usage. Measure what compression actually buys you now. For bulk transfers, move to application-level compression.
  5. Audit exotic usernames and ProxyCommand chains if any tooling constructs ssh command lines from untrusted input — the new validation may reject things you used to get away with.

OpenSSH 10.6 is available from the mirrors at openssh.com. It's not a flashy release — but between the post-quantum groundwork and the honest admission about who's finding the bugs, it's one of the most telling ones in years.

Sources: OpenSSH 10.6 release notes — https://www.openssh.com/releasenotes.html ; "Crossing the Streams: SSH Plaintext Recovery via a Common Compression Context in Multiplexed Channels", Fabian Bäumer & Marcus Brinkmann (preprint) — https://arxiv.org/abs/2609.07709