OpenSSH 10.6 turns off LZ77 compression to stop a cross-channel plaintext leak

The paper's title describes the bug almost completely: "Crossing the Streams: SSH Plaintext Recovery via a Common Compression Context in Multiplexed Channels" ^[4]. Channels carried on one SSH connection compress against shared state. An attacker who can push chosen input into one channel and watch ciphertext lengths can recover secret data sent on another ^[4]. The coder OpenSSH turned off is the part that keeps the shared dictionary, and the project says that dictionary behavior is what the attack relied on ^[3]. LWN reports the change lands in both ssh and sshd ^[5].

Two conditions have to hold at once: compression switched on, and an attacker with a channel that carries chosen input ^[16]. According to the researchers, it is not known how often those coincide in real deployments ^[16]. OpenSSH's maintainers had already advised against compression on connections that mix trusted and untrusted traffic ^[17]. Hosts that followed that advice were not running the configuration the attack needs ^[22].

Hosts that enabled `Compression` to save bandwidth pay for the fix. The option still exists but does less ^[2]. Release notes for 10.6 recommend application-level compression where practical ^[2]. For a file transfer, that means the tool compresses its own payload before SSH carries it. I think this is the right default for code built into so many operating systems and products ^[19]. The efficiency loss hits only hosts that opted into compression, while the leak could reach data on any other channel sharing their connection ^[4].

Compression shows up in one more fix, for compressed payloads larger than the supported packet size ^[13]. The SFTP client now validates server-returned paths more strictly, so a malicious server cannot steer a recursive copy outside its target directory ^[10]. GSSAPI authentication no longer keeps credentials from failed attempts, and it resets its state between tries ^[12]. Other fixes cover command-line usernames containing dollar signs or backslashes, a shell-injection risk in some configurations, and the authorized_keys `restrict` keyword for tunnel forwarding ^[13]. Runtimewire describes these as specific hardening measures, not a claim that every configuration was exposed ^[15].

The cadence change has a stated cause. According to the maintainers, they have received a large number of security reports built on AI model findings or AI-assisted analysis, and many are not security issues under a realistic threat model ^[6]. Some AI-identified bugs were later found independently by another researcher ^[6]. When two parties can find the same bug on their own, a fix held for a scheduled release gives the next finder time to use it. The project's announcement, as quoted by LWN, says: "We very much welcome these reports, especially when combined with human triage, analysis, test-cases and particularly when accompanied by proposed fixes" ^[8]. Fixes will now ship in more frequent releases instead of waiting for the next planned one ^[7]. The release notes do not quantify the reports or say how many produced fixes ^[9]. The project also says few of the companies that ship OpenSSH in their products help fund it ^[20].

On the post-quantum side, 10.6 enables `ssh-mldsa44-ed25519`, a hybrid signature that pairs ML-DSA-44 with Ed25519 ^[11]. Keys created with the earlier experimental version must be regenerated or removed ^[14]. A new server option, `WarnWeakCrypto`, is on by default and logs when a client uses key agreement that is not post-quantum safe ^[21]. Every such client will produce a log line after the upgrade ^[21]. The remote-to-remote `scp -R` option is deprecated over security risks and will be ignored in a future release ^[18].

OpenSSH ships inside operating systems and commercial products ^[19]. Each of them picks up the compression change and the faster release stream only when its vendor ships 10.6 and the releases after it ^[19][7].