The compatibility list is the upgrade plan.
OpenSSH 10.6 was released on October 6. The release notes call out three potentially incompatible changes. Compression is less effective after the LZ77 dictionary coder was disabled. Command-line destination usernames now reject $ and backslash. A small group of old platforms lose gateway and stream-local forwarding because their post-authentication process retains root privilege.[1]
The same release starts deprecating scp -R. That mode runs scp on a remote host and requires credentials there. OpenSSH says the option is fragile and can meet different shell quoting rules on the remote machine. It now prints a warning and will be ignored in a future release. The default remote-to-remote path transfers through the local host.[1][2]
A successful login does not clear the transfer route, forwarding path, or warning log.
Compression is now a trust-boundary question.
OpenSSH disabled the LZ77 dictionary coder to address a chosen-plaintext attack against trusted and untrusted channels that share one compression context. The client and server manuals already warn against compression when an open forward carries untrusted traffic beside trusted session data.[1][3]
Do not benchmark the upgrade with one shell prompt. Test the workloads that depended on compression. If they now move fewer useful bytes per second, move compression into the application where each data stream owns its own context.
New controls need separate decisions.
The release enables the hybrid ssh-mldsa44-ed25519 signature algorithm. Keys made with the earlier experimental vendor-suffixed form must be regenerated or removed. Servers also gain WarnWeakCrypto, enabled by default, so they can log connections without post-quantum key exchange. New AgentSocketPath and ssh-agent -A options let administrators choose user-specific or shared socket directories.[1][4]
Those are independent changes. Enabling a new signature does not prove every client negotiates it. Moving an agent socket does not prove file ownership or forwarding policy. Read the effective configuration, exercise the connection, and inspect the server log.
Run four checks before fleet rollout.
- Search scripts for
scp -R, untrusted username interpolation, explicit compression, and experimental ML-DSA key names. - Print effective client and server configuration on a canary host. Save package versions and the exact host stanza.
- Exercise login, remote-to-remote copy, every required forward, and the largest compressible transfer.
- Inspect weak-crypto warnings and compare negotiated algorithms before approving wider rollout.