Stop baking your identity into SSH keys that never expire

Technical Briefing | 7/27/2026

You probably have a file in your home directory called id_rsa that was generated in 2017. It has no passphrase, it is backed up on three different laptops, and you have no idea which servers still trust its public counterpart. We treat SSH keys like permanent passwords, which is exactly why our audit logs are full of mystery logins. Relying on static keys in a world that assumes identity should be verified on every hop is just asking for a credential leak that you will never be able to rotate out.

Why static keys are a production liability

The fundamental problem is that a static key doesn’t know anything about context. It doesn’t care if you are connecting from a secure office network or a cafe, and it certainly doesn’t care if your employment status changed yesterday. When you keep your keys on disk for years, you are effectively creating a back door that stays open until you manually remove every public key from every authorized_keys file on every server. That is a sysadmin’s nightmare.

ssh-keygen -t ed25519 -C "user@example.com" -f /tmp/id_temporary -N ""

• Stop trusting keys stored in plain text on developer laptops
• Switch to short-lived certificate-based authentication
• Automate the removal of stale public keys using an identity provider
• Use agent forwarding sparingly as it can be exploited if the local host is compromised

The shift toward ephemeral identity

The right way to handle this is to treat SSH sessions like ephemeral tokens. Using an SSH Certificate Authority, you sign keys that are only valid for eight hours. When the cert expires, the key is useless. You do not need to clean up servers; you just need to ensure the CA is still trusted. If you have to deal with the pain of managing thousands of static keys, start by auditing your authorized_keys files to see which ones haven’t been used in the last month, then delete them without asking for permission.

Next time you find yourself copying an SSH key to a new box, pause. Ask yourself if that server actually needs long-term access or if you are just being lazy because managing a CA feels like extra work. Your future self—and your security team—will thank you when the inevitable breach attempt hits a wall instead of an open door.