Fearless SSH: Short-lived certificates bring Zero Trust to infrastructure

Original Article ↗ Hacker News Discussion ↗

Overall Reaction to Cloudflare’s “Fearless SSH”

  • Many welcome short‑lived SSH certificates and CA-based auth as a good practice, especially for larger orgs and compliance-heavy environments.
  • Others are skeptical of outsourcing SSH CA and session control to a third party, particularly Cloudflare, seeing it as recentralization and a new single point of failure.

SSH, “No SSH,” and Operational Practices

  • Some argue any SSH access in production is an antipattern; prefer immutable OS, IaC, strong observability, and tools like AWS SSM or kubelet instead of direct shells.
  • Others counter that real-world debugging (hardware quirks, cloud bugs, subtle network issues) still needs low-level access and tools like tcpdump/eBPF.
  • Broad agreement that:
    • Routine SSH into prod is a sign of immature ops.
    • There should be “break-glass” or last-resort access, ideally audited and triggering rebuild/“taint” of touched nodes.
    • Tradeoffs depend heavily on scale and organizational maturity.

Zero Trust Terminology and Trust Model

  • Multiple commenters say the “Zero Trust” label is marketing-heavy and confusing.
  • Clarified meanings in the thread:
    • Not trusting the internal network by default; always authenticating users/services.
    • Shifting trust from network location to user/service identity.
  • Strong criticism that, in practice, this approach just replaces trust in the private network with trust in Cloudflare’s infrastructure, keys, and CAs.

Cloudflare as MITM, Auditing, and Privacy

  • Session recording and command logging are seen by some as necessary for compliance (SOX, PCI, SOC2, FedRAMP).
  • Others describe this as effectively a sanctioned MITM “keylogger,” emphasizing how much power and visibility Cloudflare gains.
  • Debate over whether such language is alarmist vs a fair way to highlight the depth of that trust.

SSH CAs, Host Keys, and Alternatives

  • Many endorse SSH certificates and internal CAs; question why an external CA is needed when orgs control both clients and servers.
  • Short‑lived certs are praised for revocation and access scoping; contrasted with sprawling, never‑rotated authorized_keys.
  • Some want better solutions for host key verification (SSH CAs, SSHFP/DNS, TPM attestation).
  • Alternatives mentioned: Teleport, Tailscale SSH, Boundary, hoop.dev, custom JWT/HTTP shells, SSM-based systems, and pure IaC approaches.