$RodHat_
MOTD

OpenSSH is finally done pretending your 2009 SSH config was acceptable

Published by

System with various wires managing access to centralized resource of server in data center
Photo: Brett Sayles / Pexels

The OpenSSH project has been quietly removing the furniture from the living room of terrible ideas for the better part of a decade, and at some point this week I noticed that another tranche of legacy algorithms has been deleted (not disabled — deleted, as in the code is gone and a grep would find nothing). DSA host key support: gone. SHA-1-based key exchange: gone. The sntrup761x25519-sha512@openssh.com hybrid post-quantum exchange — which has been the first-preference KEX since 8.5 — is giving way to ML-KEM-768 hybrid on systems running current client and server. Progress.

My opinion: good. All of it. Take it further.

Now let me tell you what’s going to break.

The problem isn’t your servers. It’s everything else.

Most of the machines you administer with up-to-date operating systems have been running fine through all of this, because OpenSSH on Linux updates continuously and the defaults march forward and you either noticed or didn’t, but it worked.

The things that break on algorithm removal are the things that never update: that FortiGate running a firmware version from 2021, the out-of-support NAS you’re using as a backup target because it was expensive and still works, the Juniper router that requires a specific vendor-blessed image and the upgrade path is “open a TAC ticket and budget three weeks,” the embedded Linux controller somebody installed in an HVAC system in 2014 that connects to your monitoring infrastructure over SSH because it was the least bad option at the time.

Every one of these things thinks it’s connecting to your SSH server the same way it always has. It is not. At some point it isn’t, anyway — and that point is whenever your distro ships an OpenSSH update and you apply it without auditing sshd_config for override flags.

The failure mode is not graceful. You get no matching key exchange method found and then silence, and then someone calls you because the monitoring dashboard went gray and they don’t know why.

The part I want to give them

The incremental deprecation approach the OpenSSH team has used — disable first, then reintroduce as a non-default option under a legacy flag, then delete when the legacy flag has been around long enough that ignoring it is a choice — is the correct way to retire cryptographic primitives in widely-deployed infrastructure software. They’ve been signaling these changes in release notes for years. If you got caught by DSA removal, you had roughly six years of warnings.

That said, most people do not read OpenSSH release notes. They run apt upgrade and then find out what changed when something breaks. The OpenSSH team knows this. The warnings appear in the release notes anyway. There’s a philosophical position embedded in this choice — that the correct users of this software read the documentation — that I happen to agree with, and that approximately zero product managers would sign off on.

What you should actually do now

  1. Audit your sshd_config for override flags. If you’ve got a KexAlgorithms line that explicitly includes diffie-hellman-group14-sha1 because some device needed it two years ago, you know about it. If you don’t have that line, you’ve been inheriting the defaults and may not know what that means. Find out now, not when you need to connect to something at 0300.

  2. Inventory SSH clients you don’t control. Network gear, NAS boxes, embedded controllers, monitoring agents that speak SSH as a collection protocol. Map them to firmware versions and whether those firmware versions are still getting cryptography updates. Most aren’t.

  3. Know which devices need legacy overrides and put them in a comment. If you’ve got a Match Address block with legacy KEX for a specific device, write down which device and what firmware in the comment next to it. When the device is upgraded or decommissioned, you remove the override. This is just basic maintenance bookkeeping that somehow nobody does.

  4. Rotate RSA keys if you haven’t. DSA is gone. But RSA 1024-bit was bad for so long that if you have any of those floating around on older systems, they should have been replaced when Obama was still in office. Ed25519 everywhere, no exceptions.

If you’re managing SSH credentials across a team and it’s still “everyone has a file in ~/.ssh/,” the 1Password SSH agent is worth a look — it gets SSH keys out of the filesystem and into an auditable secret store without requiring you to change how SSH actually works.

The algorithms are going. They should go. Your job is to know what in your environment is still depending on them before the default changes do it for you.

For the actual syscall and kernel-level context on why these cryptographic primitives have the failure modes they do, Stevens’ APUE won’t explain OpenSSH specifically but will give you the UNIX foundations that make all of it make sense. TCP/IP Illustrated for the wire-level view.