You probably missed it. Buried in the OpenSSH 10.4 release notes, between bug fixes and minor improvements, is a line about post-quantum key types — composite ML-DSA 44 combined with Ed25519. It’s a genuine cryptographic milestone. It’s also opt-in. And if history is any guide, it’ll stay opt-in for years.
The gap between inventing a security feature and actually using it is where your infrastructure quietly rots.
Here’s the pattern. Back in 2019, OpenSSH added post-quantum key agreement. Impressive, forward-thinking, the right thing to do. It didn’t become enabled by default until 2022. Three years. That’s not a bug in the process — it IS the process. And it’s happening again.
The new ML-DSA 44 + Ed25519 composite keys are designed to survive a future where quantum computers can shred classical cryptography like wet paper. That future might be five years away or fifteen. Nobody knows. But the threat is real enough that NIST has been standardizing post-quantum algorithms, and OpenSSH is implementing them. The math is solid. The deployment? Glacial.
Meanwhile, you know what’s still enabled by default in OpenSSH? hmac-sha1. umac-64. Algorithms that have been on every security team’s deprecation list for years. The tools you use to secure your servers are simultaneously preparing for quantum threats and clinging to legacy crypto that’s weak today, right now, against classical attackers.
Your SSH configuration is a time capsule: it protects against a threat that doesn’t exist yet while leaving the door cracked for threats that already do.
This isn’t a hit piece on OpenSSH. The maintainers are making rational choices. They can’t just flip a switch and break compatibility for millions of servers, embedded devices, and automated pipelines. If they forced post-quantum keys by default, half the internet’s infrastructure would grind to a halt on upgrade day. The inertia is real. The caution is justified.
But let’s be honest about what that caution costs. Every year a security feature sits opt-in is a year most people don’t use it. System administrators are stretched thin. They don’t audit release notes for cryptographic improvements. They run apt upgrade and move on. The feature exists on paper, in the source code, in the documentation — and nowhere else.
Cryptography doesn’t fail because the math is wrong. It fails because adoption is someone else’s problem.
If you manage infrastructure, this release is your wake-up call. Not because OpenSSH did something wrong, but because the default configuration is a compromise between progress and compatibility — and that compromise leaves you exposed on both ends. You’re not protected against quantum attacks because the new keys are off. You’re not fully protected against classical attacks because the old algorithms are still on.
The real question isn’t when quantum computers will arrive. It’s when you’ll stop trusting defaults and start making deliberate choices about what secures your infrastructure. Because the defaults are designed to keep everything running, not to keep everything safe.
OpenSSH 10.4 gave you the tools. They’re sitting right there, opt-in, waiting. Three years from now, when they finally flip the switch, you’ll either be ready — or you’ll be scrambling.
In security, the future doesn’t arrive suddenly. It waits patiently in a config file nobody reads.
FAQ
Q: If the algorithms are opt-in, isn't that just responsible rollout?
A: Responsible, yes. But responsibility cuts both ways. Keeping legacy crypto enabled by default while new protections sit unused isn't cautious — it's a calculated bet that your users won't get targeted before the defaults catch up. History shows that bet takes years to pay off.
Q: What should I actually do with this information?
A: Audit your SSH config today. Disable hmac-sha1 and umac-64 if you can. Test the new ML-DSA 44 + Ed25519 composite keys in a staging environment. Don't wait for OpenSSH to flip the default — by then, you'll be years behind.
Q: Isn't quantum computing still science fiction?
A: Maybe. But the intelligence community operates under a 'harvest now, decrypt later' assumption — adversaries are storing encrypted traffic today to crack tomorrow. If your data needs to stay confidential for 10+ years, the threat isn't future. It's already happening.