OpenSSH 10.6 removes shared LZ77 compression and blocks $/\ in command‑line usernames – what engineers need to know

OpenSSH 10.6 makes two concrete changes that affect how engineers use SSH: it disables the LZ77 dictionary component of the built‑in compression engine, and it rejects the characters $ and \ in usernames supplied on the command line. Both adjustments are driven by security research and have immediate operational consequences for anyone who scripts SSH connections, runs CI jobs, or relies on compression for low‑bandwidth links.

Compression redesign in OpenSSH

The new release removes the shared LZ77 dictionary from both ssh and sshd, keeping only the Huffman coding stage. The decision follows a paper by Fabian Bäumer and Marcus Brinkmann that showed a cross‑channel compression context could leak plaintext when an attacker can inject chosen data into one channel and observe the encrypted traffic length of another. By eliminating the dictionary, the attack surface that mirrors CRIME/BREACH‑style length‑based leaks is closed.

Practically, compression still works but with reduced effectiveness. Interactive shells are unlikely to notice a performance dip, but batch jobs that move large, highly compressible payloads over constrained links may see slower transfers. OpenSSH now recommends moving compression to the application layer, where it can be tuned without exposing the SSH session to the same state‑sharing risk.

Username parsing hardening

OpenSSH 10.6 adds a strict validation step for usernames passed directly on the command line. The characters $ and \ are now rejected because they can be interpreted by the shell when the username later appears inside directives such as ProxyCommand or Match exec. This prevents accidental command injection from tools that construct SSH invocations like ssh "$INPUT_USER@host". The restriction does not apply to usernames defined via the User directive in an SSH configuration file, so existing accounts that contain those characters remain functional when configured that way.

Any automation that injects usernames directly – for example CI agents, deployment scripts, or bastion‑access wrappers – must be updated to either avoid those characters or switch to a config‑file‑based approach. Failure to do so will result in immediate connection failures with a clear error about illegal characters.

Other release notes that may affect automation

• The hybrid post‑quantum signature algorithm ssh‑mldsa44‑ed25519 no longer carries the experimental @openssh.com suffix. Keys generated with the older naming must be regenerated or removed.
• The scp -R remote‑to‑remote copy mode now emits a warning and is slated for eventual removal. Scripts that rely on recursive remote copies should plan to migrate to rsync or explicit scp loops.

Related CloudNinjas coverage: DevOps.

What This Means For Practitioners

• Audit your SSH‑based pipelines for any use of $ or \ in command‑line usernames and refactor them to use configuration files or sanitized inputs.
• Measure the impact of reduced compression on any long‑running data‑transfer jobs; consider enabling application‑level compression (e.g., gzip or zstd) instead of relying on SSH’s built‑in option.
• Review key inventories for the ssh‑mldsa44‑ed25519 algorithm and re‑issue keys without the experimental suffix before the next upgrade.
• Replace scp -R usage with alternatives to avoid future deprecation warnings.
• Stay tuned for more frequent OpenSSH fix releases, as the project has indicated a shift away from its traditional release cadence.