OpenSSH 10.6 Disables SSH Compression, Adds Post-Quantum Signatures and Speeds Security Fixes

This matters to Windows admins as much as to Linux admins. SSH now runs Git pushes, jump-host sessions, Ansible runs, SFTP transfers and remote management on mixed Windows and Linux fleets. A change in how quickly OpenSSH fixes reach users eventually reaches everyone who depends on it.

AI bug reports are changing the release schedule​

The release announcement says "Recently the OpenSSH team have received a large number of security bug reports, many of which are findings from AI models or made with AI assistance." The maintainers are not presenting this as a breakthrough. They add that many AI reports are determined not to have security impact when considered in the context of a realistic threat model, and they say they welcome these reports most when they come with human triage, analysis, test cases and proposed fixes.

The reasoning behind the faster schedule is what stands out. Help Net Security reports that the maintainers have seen cases where a different researcher independently found the same bug later. In the release notes, OpenSSH concludes that attackers who never report bugs can probably find them too. So, in Help Net Security's summary, the project will ship releases more often for now to get bugfixes into users' hands more quickly.

Two points the headlines tend to skip:

• This isn't new in 10.6. The OpenSSH 10.5 release notes, dated August 11, 2026, contain almost the same wording about AI-assisted reports and more frequent releases. Version 10.6 repeats it.
• "For now" means for now. The project gives no target cadence and does not say how many reports came from AI. Its own dates show the change already: 10.4 shipped July 6, 10.5 on August 11, and 10.6 on October 6. That's gaps of about five and eight weeks. One outlet described 10.6 as arriving roughly a year after 10.5, but OpenSSH's published dates contradict that.

There is also a named AI credit. Linuxcompatible.org notes that several patches are credited "with Chris Rohlf in collaboration with Claude and Anthropic Research." H2S Media counts two such fixes.

Section summary: AI-assisted bug hunting is one stated reason OpenSSH is releasing faster. The project still describes many AI reports as noise, and it has not committed to any particular schedule.

How the compression attack works​

The biggest technical change is to compression. OpenSSH 10.6 disables the LZ77 dictionary coder in both ssh and sshd. The fix responds to a paper by Fabian Bäumer and Marcus Brinkmann, Crossing the Streams: SSH Plaintext Recovery via a Common Compression Context in Multiplexed Channels. The paper was posted to arXiv in September 2026 and has been accepted at ACM CCS 2026. The same pair helped discover the Terrapin attack, which OpenSSH addressed in 9.6.

The core problem:

1. One SSH connection can carry several channels at once, such as an interactive shell and a port forward.
2. All of those channels share a single compression context.
3. LZ77 saves space by replacing repeated strings with back-references to earlier data.
4. If an attacker can put text into one channel and that text matches a secret in another channel, the compressed output gets shorter.
5. Encryption hides the content but not the length. Someone watching the network who can also inject guesses can recover the secret piece by piece.

If you followed the CRIME and BREACH attacks on HTTPS, this will sound familiar. The authors describe it as, to their knowledge, the first compression side-channel attack on SSH.

The conditions are narrow, and that matters for judging the risk. The paper requires all of the following:

• compression is turned on
• several channels are multiplexed in the same direction on one connection
• one channel carries a secret and another accepts partly attacker-chosen input
• the secret is sent repeatedly

The researchers built three proof-of-concept scenarios: injection through a forwarded TCP port, browser-based injection into a forward bound to loopback, and recovery of an Ansible privilege-escalation password sent over a session channel. In the least noisy scenario, they recovered an 8-character secret drawn from a 26-letter alphabet in at most 276 guesses.

That figure is the best case in a lab, not a typical result. Of the 33 SSH clients the researchers surveyed, only four preferred compression by default. They also say they did not measure how often all the conditions occur together in real deployments. Noise, padding, application behavior and browser restrictions can all weaken the attack.

What changes for you​

As Linuxiac puts it, SSH compression will be less effective. The project recommends application-level compression where possible. OpenSSH's notes say compressing above SSH is usually more effective anyway and is completely immune to this attack. The documentation already advised against compression on connections that mix trusted and untrusted traffic. Version 10.6 simply applies the fix for everyone. OpenSSH also now ensures that compressed payloads cannot grow past the maximum packet length, a separate issue reported by Oleh Konko.

If you rely on Compression yes over slow links, compress the data before you send it. Archiving with zstd or gzip first, or using a transfer tool with built-in compression, is the safer approach.

Post-quantum signatures: regenerate any test keys​

The hybrid signature algorithm ssh-mldsa44-ed25519 is now enabled by default. In 10.4 it was experimental and had to be added manually to options such as HostKeyAlgorithms and PubkeyAcceptedAlgorithms. According to Linuxiac, keys created using the earlier experimental @openssh.com version should be regenerated or removed. If you tested the experimental version over the summer, those keys will not work with 10.6.

On the server side, WarnWeakCrypto is now available in sshd_config. Until now it was a client-only option. It is on by default and logs connections using key exchange methods that are not considered post-quantum safe. It only logs. It does not block anything. That makes it a cheap way to find clients that still need upgrading before "harvest now, decrypt later" becomes a compliance question.

The other security fixes​

• Username injection: ssh now rejects $ and \ in usernames typed on the command line. This blocks a shell-injection path through ProxyCommand and Match exec. Usernames set with the User directive in config files are exempt. The fix was reported by SecBuddyF of KeenLab Tencent (CodeBuddy Security). OpenSSH warns that this kind of mitigation can never be complete, given how many different shells and configurations exist.
• SFTP path validation: sftp now checks paths returned by the server more strictly, so a malicious server can't steer a recursive copy into writing outside the target directory. Junghoon Cho reported the issue and supplied the patch.
• GSSAPI handling: sshd now stores GSSAPI credentials only after authentication succeeds, and it resets GSSAPI state before each attempt. Before this, credentials from a failed attempt could persist and become available after a later successful login. Moritz Theile is credited.
• Certificate expiry times: ssh-keygen had a daylight-saving date-conversion bug that could put certificate expiry times off by up to an hour, or two hours in the Antarctica/Troll timezone. If you use short-lived SSH certificates, this one is worth noting.
• restrict and tunnels: sshd now applies the restrict keyword in authorized_keys to tunnel forwarding (PermitTunnel, which is off by default). This is separate from the restrict fix in 10.5.
• Older Unix platforms: On systems that can't pass file descriptors and need root to allocate a PTY, including QNX 6, SCO OpenServer 5 and builds made with --disable-fd-passing, the post-login process keeps root privileges. On those builds, GatewayPorts and StreamLocalForwarding are now forcibly disabled, and support for these platforms may be removed in a future release.
• macOS: On OS X SDK 27 and later, sshd sandboxing is no longer supported, because Apple removed the API OpenSSH relied on.

Smaller changes​

• scp -R (remote-to-remote copy that runs scp on the remote host) is deprecated. In 10.6 it still works but prints a warning, and a future release will ignore it. As daily.dev advises, administrators relying on remote-to-remote scp copies should plan to switch to an alternative transfer method before support is removed.
• According to H2S Media, the default number of KDF rounds for passphrase-protected private keys rises from 24 to 32.
• New additions include -p for sftp's mkdir, fractional-second ChannelTimeout values, configurable agent socket paths, and a -P flag for ssh-add that skips PIN entry on tokens that don't need one.

What Windows admins should do​

Windows includes OpenSSH as an optional feature, using Microsoft's own port of the code. Microsoft has not said when 10.6 will reach that port, so don't assume Windows machines have these fixes yet. A sensible checklist:

1. Check which version you have. Run ssh -V on Windows clients, servers and the Linux hosts they connect to.
2. Check for compression. Search ssh_config and sshd_config files and scripts for Compression yes or ssh -C. Pay most attention to sessions that combine port forwards with sensitive traffic.
3. Regenerate experimental post-quantum keys. Any @openssh.com ML-DSA keys you created for testing need replacing.
4. Prepare for the new log entries. Once Linux servers run 10.6, WarnWeakCrypto will start reporting clients that are not post-quantum safe.
5. Find scripts that use scp -R and move them to a different transfer method.
6. Shorten your patch cycle for SSH. If releases keep coming every five to eight weeks, a quarterly update schedule leaves fixes sitting unapplied.

Analysis​

AI-generated bug reports have a mixed reputation. Some open-source maintainers have complained loudly about floods of low-quality AI submissions, and OpenSSH itself says many reports turn out to have no real impact. Even so, the project has concluded that the useful findings are valuable enough, and likely enough to be rediscovered by attackers, that it should ship faster. That is a notable admission from one of the most conservative projects in security.

The cost falls on administrators. Faster releases mean more to track and more testing, which is a lot for software that holds the keys to entire server fleets. The alternative is waiting longer for fixes to bugs that other people may also be finding, and for most organizations that is the worse option.