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

Original Article ↗ Hacker News Discussion ↗

Short‑lived SSH certificates tied to single sign-on are being promoted as a way to bring “zero trust” access control and auditing to infrastructure, but many engineers question whether outsourcing this to Cloudflare—or any third-party CA—simply centralizes risk and creates a powerful MITM point. Commenters contrast this model with traditional SSH keys, self-hosted certificate authorities, and alternatives like AWS SSM or fully immutable infrastructure, debating how much remote shell access should exist at all in mature environments. There is broad agreement that short-lived, centrally managed credentials and strong auditing are valuable, but significant skepticism about zero-trust branding and about delegating core access control to a large cloud vendor.

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.