The Change Is Already On The Clock
On April 2, 2026, the OpenSSH homepage listed OpenSSH 10.3 as the current release. That is the release line operators are looking at now, and it matters because the 10.x series is where the practical compatibility changes have landed. OpenSSH 10.0, released on April 9, 2025, removed support for the DSA signature algorithm. OpenSSH 10.1, released on October 6, 2025, added a client warning when a connection negotiates a non post-quantum key agreement algorithm. If your business still depends on older SFTP jobs, vendor drop-boxes, or unattended SSH automations, those are no longer background issues. They are operational work.
The DSA change is the simple one to explain. OpenSSH 10.0 says support for the weak DSA signature algorithm was removed, finishing a deprecation path that started back in 2015 when DSA was disabled by default. The same release notes explain the underlying limitation: DSA in SSHv2 is tied to a 160 bit private key and SHA1, which OpenSSH describes as roughly 80 bits of symmetric equivalent security. For a business owner or operations lead, the implication is straightforward. If an integration still relies on DSA keys, there is no clever workaround that avoids cleanup. The keys need to be replaced, and the connection needs to be tested end to end.
The OpenSSH 10.1 warning is less dramatic on day one, but commercially it matters just as much. A transfer may still go through, but the client now tells you when the negotiated key agreement is not post-quantum. The release notes connect that warning to store now, decrypt later risk, and the OpenSSH post-quantum page states that SSH connections should use post-quantum key agreement algorithms where possible. That same page says OpenSSH has offered post-quantum key agreement by default since release 9.0 in April 2022, and that OpenSSH 9.9 added mlkem768x25519-sha256 before OpenSSH 10.0 made it the default scheme. It also makes an important distinction: this is about key agreement, while classical signatures are more a retirement and modernization problem than a way to decrypt already captured traffic.
What makes this real project work is that the fix is rarely just “update OpenSSH.” OpenSSH’s own guidance says that if the warning appears, the best answer is to update the server so it supports at least one of the two post-quantum key agreements named on the post-quantum page. If the server is already recent enough, the next place to look is its KexAlgorithms setting, because those algorithms may have been disabled by policy. In other words, version numbers are only part of the story. You also have to inspect what each side is actually willing to negotiate.
The manuals back that up. In ssh_config(5), the default client KexAlgorithms list starts with mlkem768x25519-sha256 and the sntrup761x25519 variants before moving on to curve25519, ECDH, and finite-field DH options. In sshd_config(5), the default server KexAlgorithms list also begins with mlkem768x25519-sha256 and sntrup761x25519-sha512. OpenSSH 10.0 adds another compatibility wrinkle: it removed the diffie-hellman-group* and diffie-hellman-group-exchange-* methods from the server’s default KEXAlgorithms list. So when an old transfer path starts warning or fails outright, the cause may be DSA retirement, disabled post-quantum support, or a narrower default key-exchange set on the server side.
This is also why broad rollbacks are usually the wrong response. OpenSSH gives you ways to scope compatibility settings instead of weakening everything. In ssh_config(5), Host and Match blocks let you target specific systems or conditions. The same manual says WarnWeakCrypto enables all warnings by default, and that the no-pq-kex flag can suppress warnings about non post-quantum key exchange. The post-quantum guidance even shows the intended pattern:
Match host unsafe.example.com
WarnWeakCrypto no-pq-kexThat is the sensible operating model. If one partner is behind, isolate the exception to that host. Do not quietly lower the standard for every other SSH connection in the estate.
The same principle applies to the rest of the compatibility work. The client manual documents KexAlgorithms, HostKeyAlgorithms, and PubkeyAcceptedAlgorithms as comma-separated preference lists, and it explicitly allows you to add to defaults with a leading plus sign, remove entries with a minus, or move entries to the front with a caret. On the server side, sshd_config(5) documents equivalent controls for KexAlgorithms, HostKeyAlgorithms, and PubkeyAcceptedAlgorithms. That gives you a clean remediation path: keep modern defaults as the baseline, then write the smallest possible exception for the few systems that genuinely still need special handling.
In practice, a sensible cleanup tends to follow a short, disciplined sequence.
- List what the software can support. The manuals point to
ssh -Q kex,ssh -Q HostKeyAlgorithms, andssh -Q PubkeyAcceptedAlgorithmsto show supported algorithms. - Check what the server is actually offering. On the server side,
HostKeydefines the private host key files, and the documented defaults are ECDSA, Ed25519, and RSA host keys rather than DSA. - Control which client identity is sent.
IdentityFileandIdentitiesOnlyinssh_config(5)help make sure the intended key is used instead of every key sitting in an agent. - Use conditional blocks rather than estate-wide weakening. Both manuals document
Match, and the client manual also providesHostblocks for target-specific settings.
For unattended SFTP, the easy mistake is to stop once the transfer works again. Compatibility alone is not enough if nobody will notice the next negotiation problem until a file is missing. OpenSSH documents LogLevel on both client and server, and LogVerbose for more targeted debugging. Used properly, that gives you enough visibility during a migration window to confirm which configuration is active, capture the reason a connection succeeded or failed, and then turn the noise back down. The point is not permanent debug logging. The point is to leave behind a transfer path that someone can understand the next time defaults change.
That is the service opportunity here. A proper OpenSSH 10 cleanup is not a theory exercise about cryptography. It is an inventory of SSH and SFTP endpoints, a review of negotiated and allowed algorithms, replacement of weak or retired key material, and tightly scoped exceptions where a partner has not modernized yet. Greg can run that as a contained piece of engineering work: map the endpoints, update keys and configuration, isolate the legacy cases instead of weakening everything globally, and add simple Bash or Python monitoring so the next failure is visible immediately instead of surfacing as a quiet data-handling problem. That is why this belongs on a budget line, not on a someday list.
Need help with this kind of work?
Need a scoped SSH/SFTP cleanup project instead of another temporary exception? Get in touch with Greg.