OpenSSH 10.4 will refuse to start sshd on Linux without sandbox flags

OpenSSH 10.4 will refuse to start sshd on Linux systems that do not have SECCOMP or NO_NEW_PRIVS enabled, where earlier releases logged a warning and carried on running. LWN's writeup of the release walks through the change in more detail.

SECCOMP is a Linux kernel feature that restricts what a process is allowed to do once it starts. NO_NEW_PRIVS is a per-process flag that prevents the program from gaining new privileges. sshd uses both as part of its process sandbox, and the fail-closed behavior applies to OpenSSH builds compiled with that sandbox support enabled. On a system where one or both kernel features are unavailable at startup, previous releases logged an error and continued; OpenSSH 10.4 exits at startup instead.

That posture change lands hardest on operators running OpenSSH inside containers, chroots, or custom-built host images, where the sandbox flags are sometimes stripped or disabled to fit a particular deployment model. Distro packagers will need to confirm that their build environment supports SECCOMP and NO_NEW_PRIVS at compile time, and that they have not redefined the sandbox-related compile flags in their packaging. Anyone testing 10.4 in a sandboxed jail where the kernel denies one or both flags should expect sshd to refuse to start until the jail policy is updated. The official release notes document the change alongside the rest of the changelog.

Alongside the sandbox flip, 10.4 introduces experimental support for a composite signature scheme that pairs ML-DSA 44, a NIST-standardized post-quantum signature algorithm, with Ed25519, a classical elliptic-curve signature already widely used in SSH. A composite signature carries both halves; the IETF draft describes the hybrid as a hedge so that security holds as long as at least one of the two primitives remains unbroken. The support is marked experimental in 10.4 and is not wired up as the default host key or user key type.

The experimental tag signals that the IETF composite-signatures draft is still a working document rather than a standards-track RFC, and that ML-DSA 44 was standardized by NIST only in 2024. Pairing it with Ed25519 is meant as a hedge: if a sufficiently large quantum computer ever becomes a realistic threat to either algorithm, the other half of the signature still has to fall before an attacker can forge a session. For now, the cost of the new key type is a larger handshake and a key form most operators will not yet need to deploy.

For sysadmins, the next step is to confirm whether their build configuration enables the sandbox flags before scheduling the upgrade, rather than after sshd refuses to start in the middle of a maintenance window.