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

Original Article ↗ Hacker News Discussion ↗

What OPKSSH Actually Is

  • Not a new SSH implementation; it’s a sidecar around standard OpenSSH.
  • Uses AuthorizedKeysCommand (like AWS instance-connect) to validate keys via OpenID Connect, no code changes to SSH client/server.
  • Client runs opkssh login, which obtains an ID token, derives a short-lived SSH key, and writes it to ~/.ssh/. Normal ssh/sftp then work as usual.
  • Works with existing authorized_keys; OPKSSH is effectively an additional “virtual” authorized-keys source.

Perceived Benefits

  • Single Sign-On for SSH without running an SSH CA or modifying OpenSSH.
  • Leverages existing OIDC IdPs and their lifecycle (revocation, rotation) instead of managing long-lived SSH keys.
  • Targeted at users who dislike managing SSH keys; admins can still keep static keys as break-glass.
  • Can, in principle, extend to CI/machine identities (GitHub/GitLab OIDC, etc.).
  • OpenPubkey also supports X.509 and cosigners, leaving room for richer trust models.

Security Model & Claimed Novelty

  • OpenID ID tokens normally lack user public keys; OpenPubkey “smuggles” a user-chosen public key into the token without changing IdPs or protocols.
  • The ID token acts as a certificate binding identity to a public key, avoiding bearer-token replay: servers see only public key + server-specific SSH signatures, not reusable secrets.
  • Author positions this as non-trivial: required deep reading of OIDC/SSH specs and OpenSSH internals, and careful design to avoid replay via AuthorizedKeysCommand.
  • Trust is concentrated in the IdP (no separate SSH CA). Cosigners are proposed to reduce IdP as single point of compromise.
  • JWKS is fetched from the IdP; caching and offline/pre-seeded keys are requested features.

Critiques, Alternatives, and Tradeoffs

  • Some argue similar results were already possible with AuthorizedKeysCommand or SSH certificates + OIDC (step-ca, Vault, etc.).
  • Counterargument: SSH CAs add another trusted party and awkward key rotation; opkssh avoids that but depends heavily on IdP correctness.
  • Several prefer SSH CA + hardware keys (Yubikey): smaller attack surface, no on-disk keys, no external verifier, good for break-glass.
  • Others advocate GSSAPI/Kerberos SSO, or alternatives like Teleport, Tailscale SSH, AWS SSM, or plain SSH keys.
  • Concern about “abusing” publickey auth instead of defining a first-class SSH auth method; some dislike being forced through browser-based flows for terminal sessions.
  • Broader skepticism about SSO centralization: account lockouts or provider failure can become catastrophic.

Implementation Gaps & Wishlist

  • Current client writes keys to disk instead of using SSH agent; agent support is acknowledged as important and planned.
  • Desire for: non-interactive/machine flows (e.g., Ansible), multiple client IDs per IdP, JWKS caching/offline mode, security audits, and better tooling for OS user provisioning.

Overall Reception

  • Strong interest and praise for clever use of OpenSSH’s configurability, mixed with significant skepticism about added complexity, central trust in IdPs, and browser-driven auth for SSH.