SYSTEM Cited by 3 sources
OpenSSH¶
OpenSSH is the dominant free implementation of the SSH
protocol suite (maintained by the OpenBSD project, since 1999). It
ships the ssh client, sshd server, ssh-keygen, ssh-add,
ssh-agent, scp, sftp, and ssh-copy-id. It is the reference
implementation for most SSH deployments on Linux/macOS/BSD and
(via Microsoft's port) modern Windows / Git Bash.
This page exists because OpenSSH's algorithm-support timeline is load-bearing on GitHub's 2025 post-quantum SSH rollout — whether a given client sees PQ protection is a direct function of which OpenSSH version it's running.
Relevant algorithm-support milestones¶
- OpenSSH 8.5 (2021-03) — added
sntrup761x25519-sha512@openssh.comas an optional hybrid post-quantum KEX (Streamlined NTRU Prime + X25519 + SHA-512). - OpenSSH 9.0 (2022-04) — made
sntrup761x25519-sha512@openssh.comthe default KEX, ahead of classical ECDH variants in preference order. This is the capability floor for github.com clients to get PQ protection on SSH. (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github) - OpenSSH 9.9 (2024-09) — renamed the algorithm from
sntrup761x25519-sha512@openssh.com(vendor-namespaced) tosntrup761x25519-sha512(standardized). Both names coexist as aliases for backward compatibility.
The @openssh.com suffix is OpenSSH's convention for experimental
/ vendor-namespaced algorithm names. When an algorithm matures,
the vendor suffix is dropped and both names are supported as
aliases for a transition window so clients that hardcoded the
older name continue to match. (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github)
AuthorizedKeysCommand: the external-verifier extension seam¶
Separate from KEX-algorithm negotiation, OpenSSH has a second
extensibility seam that is load-bearing on the OPKSSH source:
AuthorizedKeysCommand
in sshd_config lets an operator delegate the
"is this SSH public key authorized for this user?" decision to
an external program instead of (or in addition to) checking
~/.ssh/authorized_keys. The program receives the username (%u),
the key (%k), and the key type (%t), and returns success or
failure.
This is the hook OPKSSH uses to run the
OpenPubkey verifier: on every new SSH connection, sshd hands
the SSH certificate to opkssh verify, which parses the PK
Token out of the certificate's extension field and makes an
identity-based authorization decision. Two-line server-side
install:
No sshd binary replacement. Works with every OpenSSH version
that supports AuthorizedKeysCommand (6.2+, 2013). The command
runs as the user specified by AuthorizedKeysCommandUser for
privilege separation. (Source:
sources/2025-03-25-cloudflare-opkssh-open-sourcing)
This seam and algorithm negotiation compose orthogonally: GitHub's 2025-09-17 hybrid-PQ rollout upgrades the KEX primitive while preserving the key-auth model; OPKSSH flips the key-auth model (identity-based, not key-list-based) while preserving the KEX primitive. Both ride on OpenSSH's configuration hooks without binary changes.
Users can ask OpenSSH what it supports:
ssh -Q kex # list supported KEX algorithms
ssh -Q cipher # list supported symmetric ciphers
ssh -Q mac # list supported MACs
ssh -Q key # list supported key types
And can observe what a real handshake negotiated:
This is how GitHub suggests users verify that their client is
picking sntrup761x25519-sha512 against github.com's SSH
endpoint. (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github)
Role in GitHub's PQ rollout¶
- Server side: GitHub's SSH endpoints (for Git data access)
run some SSH-server implementation — presumably OpenSSH or a
derivative; the post doesn't disclose which. The 2025-09-17
rollout adds
sntrup761x25519-sha512to that server's supported-KEX advertised list. - Client side: most users run OpenSSH 9.0+ via their OS package manager (Ubuntu 22.04+, Fedora 36+, macOS 13.3+ Ventura, Git-for-Windows 2.41+). These clients auto-select the PQ hybrid via algorithm negotiation.
- Older clients (OpenSSH <8.5, PuTTY pre-0.78, etc.): fall back to classical ECDH — the connection still works, just without PQ protection.
Not covered here¶
- SSH protocol internals (message format, KEXINIT framing, binary packet protocol).
- Key-management (authorized_keys, known_hosts, certificates, ssh-agent forwarding).
- OpenSSH's large feature surface (ControlMaster, ProxyJump, LocalForward, RemoteForward, compression, etc.).
- Other SSH implementations (libssh, PuTTY, Dropbear, Bitvise, Microsoft SSH).
This page is scoped to the algorithm-support timeline that's load-bearing on currently ingested sources.
Seen in¶
- sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github
— OpenSSH 9.0 is the capability floor for auto-negotiating
sntrup761x25519-sha512against github.com's SSH endpoint.@openssh.comvendor-namespace convention explained as the reason both algorithm names work. - sources/2025-03-25-cloudflare-opkssh-open-sourcing —
OpenSSH's
AuthorizedKeysCommanddirective is the server- side extensibility seam OPKSSH uses to run the OpenPubkey verifier against incoming SSH certificates. Also, SSH certificate extension fields are what OPKSSH uses to carry PK Tokens through the SSH handshake without client-binary changes. - sources/2025-02-07-flyio-vscodes-ssh-agent-is-bananas — OpenSSH is the transport substrate for both remote development environments Fly.io contrasts: Emacs Tramp drives an interactive Bourne shell over SSH (live-off-the-land posture); VSCode Remote-SSH uses SSH to bootstrap a bash stager + Node.js-binary-agent install, then carries a WebSocket over an SSH port-forward back to the client (agent-deployment posture). Same transport, two diametrically-opposite architectures on top.
Related¶
- systems/github — the SaaS whose SSH endpoint this rollout targets.
- systems/git — the protocol carried over SSH.
- systems/opkssh — consumer of OpenSSH's
AuthorizedKeysCommandhook for OIDC-SSO-backed SSH. - systems/openpubkey — the protocol OPKSSH builds on.
- patterns/protocol-algorithm-negotiation — the rollout mechanism that lets OpenSSH version differences across clients coexist without breakage.
- patterns/ssh-certificate-extension-smuggling — the pattern OPKSSH uses to ride the PK Token through a standard SSH handshake.
- patterns/sso-with-ephemeral-ssh-keys — the identity-model pattern OPKSSH instantiates on top of OpenSSH.
- concepts/hybrid-key-encapsulation — what
sntrup761x25519-sha512is. - concepts/post-quantum-cryptography — the broader category.
- concepts/pk-token — the primitive that rides the SSH certificate extension.
- systems/vscode-remote-ssh — agent-deployment remote-dev architecture built on top of OpenSSH transport + port-forwarding.
- systems/emacs-tramp — live-off-the-land remote-dev architecture built on top of OpenSSH interactive shell.
- concepts/remote-development-environment — the architectural space the two above instantiate in opposite ways, both on top of OpenSSH.
- concepts/live-off-the-land — the posture Tramp takes over the OpenSSH shell.
- patterns/stager-downloads-agent-for-remote-control — the posture VSCode Remote-SSH takes over OpenSSH transport + port-forwarding.