Engineering Secure SSH Access for Engineers
summary
Passwords and raw keypairs are brittle at scale and vulnerable to exfiltration; instead use OpenSSH certificate-based auth with a remote signing service (HashiCorp Vault or similar), keep the CA private key in an HSM, and issue short-lived certs trusted via TrustedUserCAKeys in sshd_config. Use certificates named like client_id_ecdsa-cert.pub, apply force-command and per-device critical options (eg hostname company.com) to bind certs to a single device, and use host certs to avoid TOFU; handle clock drift and revocation in the signing layer.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 6:40SSH security for embedded devices
- 11:00Password authentication limits
- 13:30Public key authentication challenges
- 15:41GSSAPI in embedded contexts
- 17:20Certificate-based authentication
- 23:07SSH certificates in embedded use
- 29:57Host certificates and TOFU risks
- 31:04PAM authentication alternatives
- 32:13Q&A
related talks
44mEngineering Secure SSH Access for Engineers
23mAutomation with Scalable & Secure SSH
32mKeys or Certs for SSH Access? Why should I care?
41mA better way to SSH: Introducing SSH certificates
29mSSH Certificates: a way to scale SSH access
28mManaging SSH Access without Managing SSH Keys
11mIf You’re Not Using SSH Certificates You’re Doing SSH Wrong
15mUp your SSH security game