Skip to content

Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH

Summary

Cloudflare announces the open-sourcing of OPKSSH (OpenPubkey SSH) under the OpenPubkey Linux Foundation project umbrella (Apache 2.0, github.com/openpubkey/opkssh). OPKSSH was built by BastionZero (acquired by Cloudflare 2024) and previously closed-source; Cloudflare donated the code without claiming ongoing endorsement. OPKSSH lets users SSH using SSO (Google / Azure / Okta — any OIDC OpenID Provider) without adding any trusted party beyond the user's existing IdP, replacing long-lived SSH keys with ephemeral 24-hour keys generated on-demand. The protocol requires no changes to the SSH client or server — only two lines in sshd_config pointing AuthorizedKeysCommand at the OpenPubkey verifier — by smuggling the PK Token through an SSH certificate extension field. Authorization shifts from "trust this public key" to "trust this email address" (ACL file lists user emails, not keys).

Key takeaways

  • The core insight: OpenID Connect ID Tokens don't include the user's public key, so they can't directly secure SSH or E2E messaging. OpenPubkey's contribution is to add a public key to the ID Token (producing a PK Token) without changing the OIDC protocol or requiring OP cooperation. "Google says alice@example.com is using public key 0x123." OPKSSH then extends this so the PK Token serves as an SSH key. (Source: sources/2025-03-25-cloudflare-opkssh-open-sourcing)

  • Smuggling the PK Token through SSH without protocol changes. SSH public keys can be SSH certificates; SSH certificates have an extension field for arbitrary data. OPKSSH packages the PK Token into this extension, so it rides as part of the normal SSH public key and arrives at the server as a standard part of the SSH handshake. Canonical instance of patterns/ssh-certificate-extension-smuggling. (Source: sources/2025-03-25-cloudflare-opkssh-open-sourcing)

  • The server hook is AuthorizedKeysCommand. OpenSSH has supported delegating key-authorization decisions to an external program via the AuthorizedKeysCommand directive. OPKSSH points it at the OpenPubkey verifier, which parses the PK Token out of the SSH public key, verifies the token's signature against the OP's published keys, checks expiration, checks that the public key in the PK Token matches the public key field in the SSH handshake, then looks up the user's email in an authorized-users ACL file. Two-line sshd_config change:

AuthorizedKeysCommand /usr/local/bin/opkssh verify %u %k %t
AuthorizedKeysCommandUser root

No sshd binary replacement needed. (Source: sources/2025-03-25-cloudflare-opkssh-open-sourcing)

  • 24-hour default ephemeral keys eliminate the long-lived-key accumulation problem. Ylonen (SSH's inventor) is cited: "in many organizations — even very security-conscious organizations — there are many times more obsolete authorized keys than they have employees... in many organizations about 10% of the authorized keys grant root or administrator access. SSH keys never expire." OPKSSH regenerates on each opkssh login (which runs the OIDC browser-auth flow); the ephemeral SSH private key is co-located in ~/.ssh but expires on its own schedule (configurable, default 24h). Canonical instance of patterns/sso-with-ephemeral-ssh-keys. (Source: sources/2025-03-25-cloudflare-opkssh-open-sourcing)

  • Authorization flips from public-key-based to identity-based. Under classical SSH, Alice must ask Bob for his public key, copy it into the server's authorized_keys, track which keys belong to which humans, and remove the key when Bob leaves. Under OPKSSH, Alice adds bob@example.com to an authorized-users file. Server operators see email addresses in their ACL, not opaque key fingerprints, making access-tracking legible. (Source: sources/2025-03-25-cloudflare-opkssh-open-sourcing)

  • No trusted party added beyond the user's existing IdP. Positioned as the key differentiator vs. alternatives like cloud SSH bastions. The user already trusts Google/Azure/Okta for email + document access; OPKSSH extends that trust to SSH without introducing a fourth party. Security-architecture consequence: the verifier runs on the SSH server (no external service call on each login); all it does is check signatures against the OP's published JWKS (which it can fetch and cache). (Source: sources/2025-03-25-cloudflare-opkssh-open-sourcing)

  • The binding check is what prevents PK Token replay against a different session key. "The OpenPubkey verifier also checks that the public key in the public key field in the SSH public key matches the user's public key inside the PK Token." Without this, a stolen PK Token could be bound to an attacker's keypair. The public-key field of the SSH handshake secures the session; pinning the PK Token to that key is load-bearing. (Source: sources/2025-03-25-cloudflare-opkssh-open-sourcing)

  • OpenPubkey is Linux Foundation since 2023; OPKSSH is the production-complete SSH support that replaces an earlier prototype. OpenPubkey shipped a proof-of-concept SSH integration from day one, but it was "missing many important features." OPKSSH is a ground-up implementation under the same project. Cloudflare frames the donation as closing the gap between OpenPubkey as protocol and OpenPubkey as complete SSH feature. (Source: sources/2025-03-25-cloudflare-opkssh-open-sourcing)

Systems / concepts / patterns introduced

Caveats and what's not disclosed

  • No production scale numbers. This is a launch / donation post, not a retrospective. No MAU, concurrent-session count, fleet-size, or latency numbers are published. (OpenPubkey's own performance characteristics — PK Token size on the wire, verifier CPU cost, cache-hit rate on the OP's JWKS — aren't quantified.)
  • Expiration-policy mechanics are mentioned but not detailed. "The expiration policy can be set in a configuration file" but the file format, revocation semantics, and what happens to in-flight sessions at expiration are not described.
  • PK Token revocation. If a user leaves the company, the classical reset is to remove them from the OP directory; OPKSSH then fails at the identity-check step for new sessions. Existing SSH sessions continue until they end. The post does not discuss session-kill mechanisms (and structurally, none are added by OPKSSH beyond what SSH already provides).
  • OP-compromise model. If the OP itself is compromised, OPKSSH inherits the compromise — an attacker who can mint ID Tokens for arbitrary users can SSH as them. This is the same trust-model exposure as any IdP-backed SSO, and the post is explicit: "OPKSSH does this without adding a trusted party other than your identity provider."
  • FIPS posture. Not discussed. Unlike the 2025-09-15 GitHub post-quantum SSH rollout (sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github) which explicitly excluded the US region for FIPS reasons, this post does not mention FIPS at all.
  • Relationship to SSH certificate authorities. OPKSSH uses the SSH certificate format (specifically the extension field) but does not require a long-lived SSH CA; the OP is the trust root instead. The post doesn't discuss coexistence with existing SSH CA-based deployments (e.g. Smallstep or Netflix BLESS).

Connects to

Source

Last updated · 200 distilled / 1,178 read