A better way to SSH: Introducing SSH certificates
summary
SSH keys require scattering public keys to every host, never expire, encourage TOFU and are hard to revoke at scale; SSH certificates bind public keys to metadata, are signed by an SSH CA, and include a valid lifetime so compromise heals itself — examples: certificates issued to agent memory (not disk), integrate with SSO, and default lifetimes like 16 hours limit exposure. Tooling exists (e.g. small step, Netflix bless) to automate issuance, rotation and audit.
AI-written summary · about
chapters (10)
- 0:00SSH auth challenges
- 4:44Introduction
- 6:34Traditional SSH keys issues
- 19:27SSH keys in large orgs
- 20:08SSH certificates solution
- 23:47How SSH cert auth works
- 27:18Certs vs keys advantages
- 31:10Tooling for SSH certs
- 35:04Advanced use cases and integrations
- 39:45Conclusion
related talks
11mIf You’re Not Using SSH Certificates You’re Doing SSH Wrong
32mKeys or Certs for SSH Access? Why should I care?
28mManaging SSH Access without Managing SSH Keys
23mAutomation with Scalable & Secure SSH
29mSSH Certificates: a way to scale SSH access
45mZero Trust SSH
44mEngineering Secure SSH Access for Engineers- 44mEngineering Secure SSH Access for Engineers