SSH certificates: the better SSH experience

Original Article ↗ Hacker News Discussion ↗

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.”