Stop baking static SSH keys into your golden images before you lose control of them
By Saket Jain Published Linux/Unix
Stop baking static SSH keys into your golden images before you lose control of them
Technical Briefing | 8/21/2026
I still see teams hardcoding public keys into authorized_keys files during their build process. It feels like an easy win, but it creates a massive management headache when an engineer leaves or a laptop gets stolen. You end up with a sprawling collection of ghost keys that you never prune, effectively turning your infrastructure into an open door for anyone with the right private key sitting on an old backup.
Why ephemeral certificates are better than persistent keys
Instead of managing static files, move to SSH certificates. When you use a CA to sign short-lived keys, you shift from trust-by-possession to trust-by-identity. If someone’s access is revoked in your identity provider, their key becomes useless as soon as the TTL expires. It removes the need for configuration management tools to run around updating files across your entire fleet every time someone rotates their credentials.
ssh-keygen -s ca_key -I user_identity -V +5m -n root id_rsa.pub
- The -V flag sets the TTL, keeping the window for abuse extremely tight
- The -I field allows you to audit exactly who the key belongs to in your logs
- You no longer need to touch /home/user/.ssh/authorized_keys ever again
The catch is that you actually have to set up an SSH CA. Most people skip this because they assume it is too complex, but it is just a standard key pair protected by a hardware security module or a vault. Once it is running, you stop chasing SSH keys across every box and start managing identity at the entry point. Your future self will appreciate not having to scrub thousands of unauthorized_keys files during the next security audit.
