SSH certificates: the better SSH experience

Original Article ↗ Hacker News Discussion ↗

SSH certificates are pitched as a cleaner, more secure alternative to managing piles of SSH keys, especially in large or fast-changing server fleets, thanks to features like short‑lived credentials, central CAs, and role-based access. Commenters highlight real benefits for enterprises and automated environments, but also point out weak tooling, non-universal support, operational fragility around certificate authorities, and the fact that certificates don’t solve core problems like user lifecycle and authorization management. Many conclude that for small setups traditional keys plus good key distribution, or systems that centrally manage authorized_keys, may be simpler and more robust, while certificates shine mainly at scale.

Where SSH Certificates Help vs. Don’t

  • Seen as very helpful when:
    • There are many users/hosts or frequent rebuilds (e.g., daily-reinstalled dev/stage machines).
    • Host certificates avoid constant known_hosts churn.
    • Short-lived user certs give time-bound access and “break-glass” workflows.
  • Often not worth it when:
    • Small setups with a few machines and minimal key pain.
    • Infra-as-code already updates SSH keys centrally.
    • Some platforms (Dropbear, tinyssh, some Java SSH stacks) don’t support certs, so keys must be managed anyway.

Operational Complexity and Failure Modes

  • Managing an SSH CA introduces a powerful “keys to the kingdom” component that must be protected and highly available.
  • Problems cited:
    • Signer must be up and correct; outages or attacks can lock out everyone at once.
    • TTL tuning is tricky: too short → random lockouts; too long → weakens revocation benefits.
    • Debugging becomes harder with less on-box state; failures fan out instead of being isolated.
  • Some prefer a pull model: servers fetch authorized keys/roles over outbound HTTPS and apply them locally, keeping failures local.

Security, TOFU, and Revocation

  • Debate on TOFU:
    • Some say they’ve never seen TOFU exploited; risk is narrow (first connection, specific attacker position).
    • Others argue that’s like “no crash so no seatbelts” and prefer pre-distributed keys or SSHFP + DNSSEC.
    • Clarification that blindly accepting host keys is not “secure TOFU”; proper pairing still requires out-of-band verification.
  • Disagreement on whether certs reduce “pairing” effort:
    • One side: you still need secure distribution of CA roots and signed keys, so work is similar.
    • Other side: CA lets you avoid touching every server/client for each new key.
  • Revocation lists for SSH certs are seen as under-documented and rarely used; many rely instead on short-lived certs, which raises availability concerns.

Alternatives, Tooling, and Ecosystem

  • Alternatives mentioned: AuthorizedKeysCommand with HTTPS/LDAP backends, FreeIPA/SSSD, Kerberos GSSAPI, OIDC-based SSH, DNS SSHFP, and various commercial/open-source tools.
  • Some systems (e.g., internal platforms, pico.sh) use SSH cert principals for RBAC-like access.
  • Several commenters call for a clear, authoritative best-practices guide, noting current documentation and tooling around SSH certs are fragmented and often “janky.”