OpenSSH 10.4 Released With Security Fixes, Stricter Protocol Handling, and Experimental Post-Quantum Signatures

OpenSSH 10.4 was released on July 6, 2026, with multiple security fixes, stricter SSH transport behavior, portability updates, and experimental support for a composite post-quantum signature scheme. The update applies to OpenSSH 10.4 and the portable OpenSSH 10.4p1 release.

The OpenSSH release notes confirm that the release fixes issues in sftp, scp, sshd, and ssh. It also introduces potentially incompatible changes that administrators should test before upgrading large fleets.

The Canadian Centre for Cyber Security also issued an OpenSSH security advisory urging users and administrators to review the release details and apply the necessary updates for versions prior to 10.4.

What OpenSSH 10.4 fixes

The most immediate reason to update is the security patch set. OpenSSH 10.4 closes file-handling problems in sftp and scp, fixes sshd configuration and authentication timing issues, and addresses a client-side use-after-free condition in ssh during key re-exchange.

One sftp issue allowed a malicious server to cause a command-line download, such as downloading a remote path into the current directory, to land in an unexpected location. A related scp fix prevents a malicious server from writing files outside the intended target directory during remote-to-remote copies.

On the server side, sshd now fixes a problem in internal-sftp where long command lines could be silently truncated after the ninth argument. If a security-relevant option appeared later, it could be ignored.

Component	Issue fixed	Why it matters
sftp	Unexpected file destination during command-line downloads	Could let a malicious server place files where the user did not intend
scp	Remote-to-remote copy path handling	Could let a malicious server write outside the target directory
sshd	internal-sftp command-line truncation	Could discard later security-relevant options
sshd	Authentication delay enforcement gaps	Could weaken timing protections during login attempts
ssh	Client-side use-after-free during host key change	Could affect clients when a server changes its host key mid-session

Server-side fixes reduce authentication and DoS risks

OpenSSH 10.4 also fixes a potential pre-authentication denial-of-service issue when GSSAPIAuthentication is enabled. This setting is off by default, but the fix still matters for environments that rely on Kerberos or GSSAPI-based authentication.

The release also tightens minimum authentication delay enforcement in sshd. These delay controls help reduce the effectiveness of repeated authentication attempts by making server responses less immediately useful to attackers.

The official Canadian Cyber Centre advisory lists OpenSSH versions prior to 10.4 as affected and recommends applying the update. That makes the release a priority for internet-facing SSH servers and managed Linux or Unix fleets.

Transport protocol hardening may affect compatibility

OpenSSH 10.4 introduces stricter behavior during post-authentication key re-exchange. If a peer sends non-key-exchange messages during that re-exchange phase, OpenSSH can now disconnect the session.

This change closes a memory-waste scenario where a malicious peer could keep sending messages that would be buffered until the connection ended or a memory limit was hit. It also aligns OpenSSH more tightly with SSH transport rules.

The change could affect implementations that do not restrict messages properly during key exchange. Administrators who run mixed SSH clients, embedded systems, jump hosts, or older appliances should test compatibility before rolling the update into production.

Potentially incompatible change	Who should test it
Disconnects peers that send non-KEX messages during rekeying	Teams with older SSH clients, embedded SSH stacks, or custom SSH software
Fatal seccomp sandbox setup failures on Linux	Administrators using older kernels or unusual Linux builds
Mixed-case output from sshd -G	Automation scripts that parse sshd configuration dump output

Linux sandbox failures are now fatal

On Linux, OpenSSH 10.4 changes how sshd handles seccomp sandbox setup failures. If seccomp or NO_NEW_PRIVS cannot be enabled on a system where the sandbox is configured, sshd now treats that failure as fatal instead of only logging the error and continuing.

This is a security hardening change. It prevents deployments from silently running without an expected sandbox, but it can also break systems that lack the needed kernel features.

Administrators using older Linux systems or custom kernels should check whether seccomp support works correctly before upgrading. Systems that cannot support the sandbox need an explicit build-time decision rather than silently continuing in a weaker state.

Experimental post-quantum signatures arrive

The headline feature in OpenSSH 10.4 is experimental support for a composite signature scheme that combines ML-DSA 44 with Ed25519. The feature follows the ML-DSA 44 and Ed25519 composite signatures draft.

The feature is not enabled by default. Administrators who want to test it must explicitly add the new algorithm to settings such as HostKeyAlgorithms or PubkeyAcceptedAlgorithms and generate keys using ssh-keygen with the mldsa44-ed25519 key type.

The IETF draft describes a composite SSH signature scheme that combines the post-quantum Module-Lattice Digital Signature Algorithm with the classical Ed25519 signature algorithm. The goal is to provide protection against both quantum and classical adversaries while post-quantum adoption continues to mature.

• The new signature scheme is experimental.
• It combines ML-DSA 44 and Ed25519.
• It is disabled by default.
• It requires explicit algorithm configuration.
• Keys can be generated with the new mldsa44-ed25519 type.

Wildcard matching now avoids worst-case slowdowns

OpenSSH 10.4 replaces the previous wildcard pattern matcher in ssh and sshd with an implementation based on a non-deterministic finite automaton, or NFA. This change avoids exponential worst-case performance behavior in the older matcher.

Wildcard matching appears in several configuration and policy-related areas, so the performance fix matters for hardening as well as speed. It reduces the chance that specially crafted patterns can trigger excessive processing.

The release also includes several broader bug fixes, including FIDO token handling improvements, out-of-bounds read fixes in sftp, stricter transport state validation across sshd privilege separation processes, and better bounds checking in cryptographic signing code.

Other important bug fixes in OpenSSH 10.4

The update fixes ssh-agent behavior for extension queries and improves how ssh-keygen and ssh-add handle resident keys from FIDO tokens. Unsupported key types are now skipped instead of aborting the entire download.

sftp receives fixes for one-byte out-of-bounds reads in REALPATH and batch command handling. It also avoids a loop condition that could occur when a broken server repeatedly returned zero-length reads.

sshd receives a major refactor of sshd_config parsing and management so configuration can be serialized and deserialized more precisely across privilege separation boundaries. This should improve internal robustness without requiring most administrators to change configuration files.

Area	OpenSSH 10.4 change
FIDO keys	Skips unsupported resident key types during download
sftp	Fixes out-of-bounds reads and zero-length read loop behavior
Privilege separation	Improves encoding and validation of transport state
Crypto code	Adds better bounds checking and Ed25519 verification checks
Configuration parsing	Refactors sshd_config handling for cleaner serialization

Source packages and verification

The OpenSSH 10.4 release notes list source packages for openssh-10.4.tar.gz and openssh-10.4p1.tar.gz, along with SHA1 and base64-encoded SHA256 checksums. The project also provides release signing keys through official mirror sites.

Administrators should verify downloaded source packages before building or distributing them internally. This step matters for security-sensitive software such as OpenSSH, where supply-chain integrity is part of the update process.

Linux distributions and BSD projects may package the release on their own schedule. In managed environments, teams should follow their vendor’s update channel unless they build OpenSSH directly from source.

What administrators should do now

Organizations should prioritize OpenSSH 10.4 on systems that expose SSH to the internet, handle automated file transfers, or rely on internal jump hosts. The security fixes affect both client-side and server-side components, so endpoint and server teams should coordinate rollout plans.

Before deployment, teams should test scripts that parse sshd -G output, confirm seccomp compatibility on Linux, and check SSH interoperability with older clients or appliances. The stricter rekey behavior follows the SSH transport protocol, but non-compliant implementations may still fail after the update.

• Inventory OpenSSH versions across servers, workstations, and jump hosts.
• Patch OpenSSH versions prior to 10.4 through trusted vendor channels.
• Test sshd -G parsing scripts for mixed-case directive output.
• Confirm Linux seccomp sandbox behavior before production rollout.
• Review whether GSSAPIAuthentication is enabled anywhere.
• Test older SSH clients and appliances for rekey compatibility.
• Keep post-quantum signature testing separate from production unless required.

Why the release matters

OpenSSH sits at the center of remote administration, automation, file transfer, and infrastructure access. Even fixes that look narrow can matter at scale because SSH runs on servers, developer workstations, build systems, network appliances, and cloud environments.

The composite signature draft also shows where SSH authentication may be heading as post-quantum migration progresses. For now, OpenSSH treats the feature as experimental, which is the right posture for most production systems.

The transport hardening also reinforces a simple operational point. SSH compatibility should not depend on accepting behavior outside the protocol. The RFC 4253 transport specification remains the baseline for how peers should behave during key exchange and rekeying.

FAQ