OpenSSH 10.0 Security Changes: What Enterprise Defenders Need to Know

# OpenSSH 10.0 security changes: what enterprise defenders need to know

Two years is a long time between major OpenSSH releases, which means when one finally ships, it breaks things. OpenSSH 10.0 dropped on April 14, 2026. It's a good release. It's also a release that will break something in your environment if you upgrade without reading the change log.

The headline is post-quantum key agreement by default. That's the change nobody is going to fight you on. The changes that will cause incidents are the ones buried further down the list. Several legacy algorithms removed outright. Agent forwarding behavior adjusted. A new connection-caching default that makes jump hosts behave differently than they used to.

If you operate Linux infrastructure, this is the rollout plan. What to test, what to whitelist, and which vendors have already broken.

#The big change: post-quantum default

What we actually see in the field diverges from what the vendors describe. Here's the unvarnished version.

OpenSSH 10.0 makes sntrup761x25519-sha512 the first-preference key exchange algorithm, with mlkem768x25519-sha256 as an explicit option.

sntrup761x25519-sha512 has been supported since OpenSSH 9.0 (April 2022) as an option. In 10.0 it becomes the default first-preference. Both are hybrid schemes. They combine a classical elliptic curve (X25519) with a post-quantum algorithm (Streamlined NTRU Prime or ML-KEM) so a break in either one doesn't compromise the session.

The practical effect: two OpenSSH 10.0 machines talking to each other will negotiate a post-quantum-resistant session by default. Sessions between an OpenSSH 10.0 client and older server will fall back to classical X25519 or P-curve ECDH, which is still secure against current attackers but not against a future quantum computer.

The defensive value: harvest-now-decrypt-later attackers, who are recording encrypted SSH sessions today hoping to decrypt in the future when quantum computers mature, can't decrypt 10.0-to-10.0 sessions even retroactively.

#Removed algorithms

The following algorithms are fully removed in 10.0 and can't be re-enabled via configuration. If you've infrastructure that depends on them, you must either rebuild with older OpenSSH or replace the legacy system.

#Host key types

• ssh-dss (DSA). Removed. Already disabled by default since 9.x, now removed entirely.
• ssh-rsa with SHA-1. RSA host keys signed with SHA-1 are removed. RSA with SHA-256/512 still supported. If your client or server is old enough that its RSA implementation only signs with SHA-1, it won't negotiate.

#Key exchange

• diffie-hellman-group1-sha1 (DH1024)
• diffie-hellman-group14-sha1 (DH2048 with SHA-1)
• diffie-hellman-group-exchange-sha1
• gss-gex-sha1-*

#Ciphers

• arcfour family (RC4). Gone
• blowfish-cbc. Gone
• cast128-cbc. Gone
• aes*-cbc deprecated (still compiled but disabled by default. You can enable via Ciphers +aes128-cbc,aes256-cbc during transition)
• 3des-cbc. Gone

#MACs

• hmac-sha1 variants. Removed
• hmac-md5 variants. Removed

If you've network gear (old Cisco, HP, Juniper) or appliances (NAS, BMC, IPMI) that only speak the removed algorithms, your workstation won't connect after upgrade. You will need to either update the appliance, keep an older SSH client around for specific purposes, or jump through an intermediate host.

#Agent forwarding changes

OpenSSH 10.0 tightens agent forwarding semantics. The -A option and ForwardAgent yes in config are still supported but:

• Forwarded agents are now bound to the specific destination host. A forwarded agent on server A can't be used to authenticate to server B.
• Agent forwarding requests to a compromised host can no longer enumerate all keys in the agent. Only the key used to establish the session is available to the remote agent socket.
• New AllowAgentForwarding defaults to no on server-side for reverse-tunneled connections.

Practical impact: the classic "attacker compromises a jump host, reads your agent socket, uses it to authenticate to other hosts" attack becomes much harder. The classic workflow where you ssh to bastion, ssh from bastion to internal hosts, and forward agent the whole way. Still works, but the agent exposure is narrower.

If your operations relied on forwarded agents jumping across multiple internal hosts from a single external login, test before production rollout.

#New security features

#BindAddress enforcement

Client-side BindAddress now enforces. Previously some edge cases allowed it to be ignored silently. If you use BindAddress to constrain outbound SSH to specific interfaces (often in multi-homed pentest or network operations setups), the 10.0 behavior is stricter and more predictable.

#Session multiplexing hardening

ControlMaster and ControlPath now require the control socket to be on a filesystem owned by the user with mode 0700. No more sharing SSH connections through /tmp/ssh-* with permissive modes.

#Stricter authorized_keys parsing

Unknown options in authorized_keys now fail closed by default. If a line contains an option the server doesn't understand, the key is rejected than having the unknown option silently ignored.

#SFTP server hardening

sftp-server subsystem has additional restrictions on symlink traversal and canonicalized path behavior. If you use SFTP for constrained file transfer (common in SOX / PCI environments for vendor file drops), the new defaults are tighter.

#What to test before rolling out

#Client-side rollout

• Test SSH to every infrastructure component you depend on from a 10.0 client
• Specifically test: network gear, BMC/IPMI interfaces, NAS devices, printers with SSH management interfaces, legacy Unix hosts
• Identify which targets require algorithm re-enablement via config vs. which need replacement

#Server-side rollout

• Upgrade canary servers first, leave production on 9.x during the testing window
• Check CI/CD systems that SSH to build machines. Older Go, Python, Java SSH libraries often lag behind
• Git hosting: make sure your Git servers still accept your push key after rollout
• Backup systems (rsync-over-ssh, BorgBackup, Restic) need testing

#Agent-forwarding dependent workflows

• Any ops playbook that assumes agent forwards across multiple hops
• CI systems that use agent forwarding to deploy
• Ansible / Salt / Chef that uses SSH agent forwarding

#Recommended config additions

For servers accepting only 10.0+ clients (greenfield deployments):

# /etc/ssh/sshd_config
HostKey /etc/ssh/ssh_host_ed25519_key
# Drop RSA entirely if your inventory allows

KexAlgorithms sntrup761x25519-sha512,mlkem768x25519-sha256,curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

PubkeyAuthentication yes
AuthenticationMethods publickey

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no

LogLevel VERBOSE

For mixed-environment servers supporting older clients:

# Fall back to secure classical if needed
KexAlgorithms sntrup761x25519-sha512,mlkem768x25519-sha256,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512

#The CIS Benchmark impact

CIS Linux benchmarks include specific SSH configuration requirements. The 10.0 release changes require CIS to republish the SSH sections of their benchmarks. Expect new Level 1 and Level 2 benchmark versions in Q2-Q3 2026 reflecting:

• Requiring post-quantum hybrid KEX algorithms
• Removing the algorithms that are now unsupported
• Tightening agent forwarding defaults

If you configure against CIS benchmarks for compliance (PCI DSS 4.0 Requirement 2.2, CMMC 2.0 CM.L2-3.4.2, NIST 800-171 3.4.2), track the benchmark updates.

#Timing for your rollout

• April 2026: 10.0 shipped
• Most Linux distros will pick it up over summer 2026. Fedora first, Debian testing and Ubuntu HWE kernels shortly after
• Enterprise distros (RHEL 10, Ubuntu LTS 26.04 when it arrives) will have backports later in 2026

Plan your enterprise rollout for Q3-Q4 2026 unless you've specific drivers to move faster. Inventory legacy SSH-speaking devices now while you've time to remediate.

#Resources

• OpenSSH 10.0 release notes: https://www.openssh.com/releasenotes.html
• NIST PQC guidance: NIST SP 800-208 (post-quantum recommendations)
• CVE tracking for OpenSSH: https://www.openssh.com/security.html
• CIS Linux Benchmark updates: https://www.cisecurity.org/

#Hire Valtik Studios

We run infrastructure security audits that cover SSH deployment posture alongside the broader network and identity stack. Post-quantum migration is a multi-year program. SSH is one component. If you need a security audit of your SSH deployment, cryptographic migration plan, or general Linux server hardening, we handle those engagements.

Reach us at valtikstudios.com.