Comment by kkl
12 hours ago
Part of the threat model for an Engineering team is that people come and go. They move teams which have different levels of access. They leave the organization, in most cases, on good terms. I want to set up infrastructure where I don't need to remember that your SSH pubkey is baked into production configuration after you leave the company.
There are several options for setting up per-connection keys that are dispensed to users through the company SSO. That setup means you don't need to maintain separate infrastructure for (de-)provisioning SSH keys.
This is completely solved by SSH certificates. You still have the same private key in the hardware, but instead of using the public key directly, you issue temporary (~1 hour) SSH key certificates. I even automated it using an SSH proxy.
The target machines then just need to put the CA cert in the authorized_keys files.
> The target machines then just need to put the CA cert in the authorized_keys files.
The word "just" is doing a lot of work there. You update authorized_keys every hour for your entire fleet?
No, the ssh CA model works like this: servers trust one CA, and the CA signs user keys. No more distributing individual public keys to every machine.
It is the user machine that needs new certificate signed by the CA once the short-lived one expires.
1 reply →
Sounds like a job for dnssec and sshfp records
Ahh, now you have three problems…hrm