OpenSSH 10: What’s New and Why It Might Affect Your Setup

The OpenSSH project, part of the OpenBSD family, has released version 10 of its secure shell suite.

If you use SSH (chances are, you do!), for remote logins, secure file transfers, or automated access between systems, this release brings a lot of change — some helpful, some disruptive.

Let’s break down what’s new, what’s gone, and what it all means for sysadmins, developers, and security-conscious users.

🔒 DSA Support is Officially Gone

One of the most significant changes: DSA (Digital Signature Algorithm) support has been entirely removed.

This has been coming for a long time — DSA was disabled by default back in 2015 due to its aging security profile and limitations (like only supporting 1024-bit keys).

If you still have DSA keys hanging around in old configs, scripts, or user accounts, those keys will now simply stop working.

Migrating to modern key types like Ed25519 (lightweight, fast, and secure) or RSA with at least 2048-bit keys is now mandatory.

🔄 Behavioral Shift in scp and sftp

Another important change affects how scp and sftp initiate their connections. These tools now default to passing ControlMaster no to the underlying SSH command.

In short, this prevents them from reusing an existing master connection unless specifically told to do so.

This makes behavior more predictable, especially in environments where auto-multiplexing led to surprises like unexpected session sharing.

However, if you rely on connection multiplexing for performance reasons (e.g., opening many sessions rapidly), you may need to explicitly configure ControlMaster settings in your ~/.ssh/config or command-line calls.

🧩 Version Number Leap Could Break Naive Parsers

OpenSSH has jumped directly to version 10, and that might trip up some scripts or tools. Historically, many programs assume OpenSSH versions begin with "OpenSSH_1*", and don’t expect a two-digit version number.

If you use scripts that extract or parse the OpenSSH version (for compatibility checks, CI/CD workflows, or inventory tools), test them with this release to make sure they can handle the double-digit versioning.

🧱 Internals Restructured: sshd-auth and sshd-session

A bigger change happens inside the SSH daemon (sshd) itself. Previously, user authentication and session handling were all managed by a single process.

Now, authentication code has been moved to a dedicated sshd-auth binary.

Why this matters: it shrinks the attack surface of the pre-authentication code. Since this phase runs before the user is verified, it’s a critical target for exploits.

Separating it into its own process makes it easier to harden and audit, and limits potential damage in case of a bug or attack.

📉 modp (Finite Field) Key Exchange Disabled by Default

Key exchange using classic finite field (modp) Diffie-Hellman groups is now off by default. These have been gradually replaced by elliptic curve algorithms like Curve25519, which offer better performance and stronger security at shorter key lengths.

If you’re still using modp groups — for example, to support legacy clients — you can re-enable them. But this is a clear nudge to move to ECDH or hybrid post-quantum methods going forward.

🌐 Hybrid Post-Quantum Key Exchange is Now the Default

The new default key agreement method is mlkem768x25519-sha256. This hybrid algorithm combines:

• ML-KEM 768: a post-quantum algorithm designed to resist attacks from quantum computers, and
• Curve25519: a well-established elliptic curve algorithm for classical security.

By combining them, OpenSSH is future-proofing key exchange, ensuring sessions remain secure even if large-scale quantum computers become practical. While we’re not there yet, this is a major step toward readiness.

🔐 Cipher Suite Preference Tweaks

OpenSSH now prefers AES-GCM over AES-CTR. This matters because AES-GCM is an authenticated encryption method — it ensures that data hasn’t been tampered with, in addition to encrypting it.

That said, ChaCha20/Poly1305 remains the first choice for many setups due to its speed, especially on devices without hardware AES support.

⚙️ Config File Improvements

This release adds several new features that make configuration more powerful and flexible:

• Variable Expansion in ssh_config: You can now use % tokens and environment variables in more options like SetEnv and User. For example: SetEnv DEPLOY_ENV=%n This can make per-host settings much more dynamic.
• New Match Rules: OpenSSH 10 introduces Match version and Match session-type. This lets you apply settings only when connecting with certain OpenSSH versions or based on how the session is used (e.g., interactive shell vs. file transfer subsystem).

These improvements help create more fine-tuned and maintainable SSH configurations.

🛠️ Other Quality-of-Life Updates

There are several smaller — but meaningful — enhancements:

• sshd_config now supports more flexible matching for AuthorizedKeysFile and AuthorizedPrincipalsFile.
• ssh-agent has better control options for FIDO2 hardware tokens, including timeouts and constraints.
• ObscureKeystrokeTiming (a mitigation for side-channel attacks in X11 forwarding) has improved behavior.
• Large sshd config files now load more reliably, even when exceeding prior buffer limits.
• Fallbacks for Group Exchange (DH-GEX) are now more robust, improving compatibility in rare scenarios.

🧹 Bug Fixes and Cleanup

As usual, this release includes numerous bug fixes, touching on everything from corner cases in sftp to improved logging, error handling, and more robust behavior under high load or edge conditions.

Check out the release notes  for detailed information about all changes in OpenSSH 10.

In Summary

OpenSSH 10 doesn’t just bump the version number — it brings real, architectural change. It retires outdated crypto, tightens security boundaries, prepares for the post-quantum future, and makes configuration more flexible.

But with those improvements come some risks: broken scripts, outdated keys, or unexpected connection behavior.

If you manage systems that use OpenSSH — especially at scale — it’s time to test, audit, and update configs.