OpenSSH 10.6 includes two security changes that may break some previous usage scenarios: disabling the LZ77 component responsible for building the repetition dictionary in SSH compression, and rejecting usernames containing the $ and \ characters when passed through the command line. The project’s developers made the decision knowing that some environments and tools would need modification.
Why Was SSH Compression Weakened?
A single SSH session can carry an interactive terminal channel, port forwarding, or a dynamic SOCKS proxy. When compression was enabled, the channels shared a single compression state. Researchers Fabian Bäumer and Marcus Brinkmann from Ruhr University Bochum showed that an attacker could inject text of their choice into one channel and monitor encrypted traffic to infer secret data transmitted through another channel in the same session.
The attack relies on LZ77 memory, which reuses sequences that appeared previously instead of encoding them in full. When the attacker’s guess matches part of the secret, the compressed output may become slightly shorter, providing a signal that helps recover the data. This technique belongs to the CRIME and BREACH family of attacks, but it requires a specific setup: SSH compression must be enabled, the attacker must be able to control part of the traffic, and the secret and the channel under attack must be within a multi-channel SSH session.
In less noisy tests, the researchers recovered an eight-character secret from an alphabet of 26 characters with a median of 276 guesses across 100 trials. In a browser-based and noisier scenario, the number rose to approximately 27,600 guesses. According to the source material, the proof-of-concept models were built using Claude Code.
What Changes in Compression in Practice?
OpenSSH has retained Huffman coding but disabled the LZ77 component in both ssh and sshd. Compression therefore does not disappear completely, but it becomes less effective. The project says that ordinary interactive sessions will generally not notice a major difference, while automated tasks that transfer large amounts of compressible data over limited-capacity connections may be affected.
OpenSSH recommends moving compression to the application layer, where it is usually more efficient and is not exposed to this type of attack. In practice, owners of automation systems that rely on SSH compression should measure transfer size and execution time after upgrading, then determine whether compressing the data before sending it is more suitable than relying on SSH compression.
Usernames and the Automation Path
Version 10.6 rejects the $ and \ characters in usernames passed through the command line. This targets internal tools, CI tasks, and agents that build a command such as ssh "$INPUT_USER@host", after which the username may reach directives such as ProxyCommand or Match exec, where these characters can be interpreted as part of shell construction rather than ordinary data.
The same restriction does not apply when the username is specified through the User directive in an SSH configuration file. Legitimate accounts containing these characters can therefore remain usable this way, but scripts and tools that pass them directly through the command line may need modification. This follows a related fix in OpenSSH 10.3, where shell-character validation occurred too late, allowing them to reach the expansion path in ssh_config.
Additional Changes That May Affect Workflows
- The post-quantum hybrid signature algorithm ssh-mldsa44-ed25519 lost the experimental @openssh.com suffix, meaning that keys created by the previous implementation need to be regenerated or removed.
- The project began preparing to deprecate scp -R for copying from a remote host to another remote host. The option still works in version 10.6, but it issues a warning and is scheduled to be ignored in the future.
These changes show that compatibility with previous behavior is no longer an absolute priority when automated use reveals a path to data leakage or command injection. However, the practical constraints are not equal: the compression leakage risk requires a specific session and set of conditions, while username rejection may appear immediately in scripts that rely on external inputs. Operations teams therefore need to test the upgrade, review SSH command construction, and verify keys and copy options before adopting the release broadly.