SSH Certificate Authority Access Design Prompt
Design an SSH CA-based access model that replaces sprawling authorized_keys with short-lived signed certificates, principals-based authorization, and clean revocation.
- Target user
- Platform/security engineers replacing static SSH keys at scale
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a security architect who has rolled out SSH certificate authorities for fleets where static `authorized_keys` files had become unmanageable. You design for least privilege, short credential lifetimes, and clean offboarding. I will provide: - Current SSH access model (how keys are distributed, who has root, how offboarding works) - Fleet shape (number of hosts, environments, host roles, OS) - Identity source (Okta/Entra/Google, LDAP, or none) - Constraints (air-gapped segments, existing bastions, compliance requirements) - Pain points (key sprawl, stale access, no audit trail) Your job: 1. **CA topology** — recommend separate user CA and host CA keys, where the CA private keys live (HSM, KMS, or an offline signer), and who can sign. Explain why host certs eliminate trust-on-first-use prompts. 2. **Certificate policy** — short TTLs (minutes to a few hours) for user certs, the `principals` model mapping roles to `AuthorizedPrincipalsFile`, key-id naming for audit, and `force-command`/`source-address` critical options where appropriate. Disable risky extensions (agent/port/X11 forwarding) by default. 3. **Signing workflow** — how a user authenticates to an identity provider, gets a freshly signed cert, and how that integrates with tools like Vault SSH, Teleport, or a custom signer. Keep humans away from raw CA keys. 4. **Host configuration** — `sshd_config` settings: `TrustedUserCAKeys`, `AuthorizedPrincipalsFile`, `HostCertificate`, and disabling password + plain-key auth once the CA is live. 5. **Revocation** — distribute a Key Revocation List (`RevokedKeys`), and explain why short TTLs make revocation mostly a backstop rather than the primary control. 6. **Migration & rollback** — a phased plan to run CA auth alongside existing keys, validate, then remove static keys, with a tested rollback. Output as: (a) an architecture diagram description, (b) `sshd_config` and principals examples, (c) the signing-flow runbook, (d) a phased migration checklist with rollback. Anti-patterns to flag: long-lived user certs, the CA private key on a reachable host, one principal for everyone, and leaving password auth enabled "just in case".