OpenSSH 10.6 Deliberately Breaks Compression and Rejects Risky Usernames for Security
OpenSSH 10.6 weakens SSH compression and blocks special characters in command-line usernames to patch a plaintext leak and shell injection vulnerability, changes the maintainers made knowingly to close security gaps.

Released Tuesday, OpenSSH 10.6 introduces two intentional breaking changes designed to address security flaws. The update disables the LZ77 dictionary coder in SSH compression after researchers discovered that sharing compression state across multiple channels could leak plaintext data. It also rejects the $ and \ characters in command-line usernames to prevent shell interpretation through directives like ProxyCommand and Match exec.
The timing reflects a shift in the threat landscape. OpenSSH is now contending with security research conducted using AI models, which are improving at discovering exploitable vulnerabilities. OpenSSH cautioned that adversaries who withhold their findings "are likely to be able to discover these bugs too," and announced it will accelerate its release cadence rather than adhering to its traditional schedule.
Compression context leaks plaintext
A single encrypted SSH connection can multiplex several services—an interactive shell, port forwarding, or a dynamic SOCKS proxy. When compression is enabled, these channels share compression state, though OpenSSH disables compression by default, limiting the attack's scope to scenarios where it has been explicitly turned on.
Researchers Fabian Bäumer and Marcus Brinkmann from Ruhr University Bochum detailed the vulnerability in their paper "Crossing the Streams: SSH Plaintext Recovery via a Common Compression Context in Multiplexed Channels." Their work showed that an attacker capable of injecting chosen plaintext into one channel and observing the encrypted output can exploit the shared compression state to recover secrets transmitted through another channel in the same session.
The vulnerability stems from how LZ77 operates. Rather than re-encoding identical byte sequences, the algorithm references previously encountered matches. Because OpenSSH shared this history across channels, attacker-controlled data could influence how secrets elsewhere in the session were compressed. When an attacker's guess aligned with part of a secret, the resulting encrypted traffic would be marginally shorter, leaking information bit by bit.
This attack belongs to the same category as CRIME and BREACH, which targeted HTTP over TLS, though executing it here demands a specific configuration: the attacker-controlled traffic and the secret must traverse the same multiplexed SSH session. In their cleanest tests, Bäumer and Brinkmann recovered an eight-character secret from a 26-character alphabet with a median of 276 guesses across 100 trials. In a noisier browser-based scenario, recovery required approximately 27,600 guesses.
The researchers built proof-of-concept code for all three attack scenarios using Claude Code. OpenSSH 10.6 also credits Chris Rohlf, working with Claude and Anthropic Research, with discovering two additional bugs that the release addresses.
Huffman stays, LZ77 goes
OpenSSH chose a direct solution: removing the shared dictionary entirely. The Deflate algorithm combines LZ77 for identifying repeated data chunks with Huffman coding to represent frequent values using fewer bits. OpenSSH 10.6 disables LZ77 in both ssh and sshd while preserving Huffman coding.
Compression remains functional but less efficient. OpenSSH notes that the Compression option will deliver reduced effectiveness and suggests moving compression to the application layer, where it typically performs better without exposure to this particular attack.
Interactive SSH sessions will likely experience minimal impact, though automated processes transferring substantial volumes of compressible data across bandwidth-limited connections could be affected. Such workloads may require relocating compression outside SSH and into the application layer following the upgrade.
Shell metacharacters in usernames
The username restriction targets commands constructed from external input. An internal tool, CI pipeline, or agent might execute something like ssh "$INPUT_USER@host", and that username could subsequently appear within ProxyCommand, Match exec, or another shell command, where characters like $ and \ transform from username data into shell syntax.
This represents another step in an ongoing hardening effort. Version 10.3 previously patched a related issue where command-line usernames underwent shell metacharacter validation too late, after they could be expanded via ssh_config.
In 10.6, $ and \ are blocked in usernames supplied via the command line, but this restriction does not extend to usernames configured through the User directive in SSH configuration files. Legitimate accounts with these characters can still function through that method, though scripts and automation tools that pass usernames directly will require modification.
Post-quantum keys, deprecated scp
OpenSSH 10.6 includes additional changes that may disrupt automated systems. The hybrid post-quantum ssh-mldsa44-ed25519 signature algorithm sheds its experimental @openssh.com suffix, necessitating regeneration or removal of keys created under the earlier implementation. The release also begins deprecating scp -R for remote-to-remote transfers; it functions in 10.6 but now triggers a warning and will eventually be disabled.