Re: Inspiration from the podiverse, about SSH
I had a similar conversation the other day with some junior developers on my team. Our org is currently going through a SCM solution transition so we are migrating from multiple services down to one.
My personal philosophy for SSH keys is that they are both unique to the client and are one use only. Note the "one use". This means if you have a cluster of servers that you maintain having a single key on your terminal to access them all is perfectly fine. However, if you also need a key to connect to your SCM then you'd create a brand new key. If you have a desktop terminal as well as a laptop that you use when you go roaming, both machines will have their own sets of keys for these tasks.
Burning Keys?
There is an option within `ssh-keygen` to set a validation date for your keys. I have never found this super useful. Services like an SCM already include an expiration on their side so I set it there. Unlike PGP, SSH keys don't have the burn process built in to tell the world your key is not to be trusted. One must go to each service and kill it and replace with a new key so expiration doesn't do much.
The other benefit for PGP keys or an SSL certs having expirations is that the process of updating or replacing the key shows others that you are still active. This isn't the case for SSH keys. No one is looking at your key besides the server or service you are interacting with.
Just use ssh-agent
I keep an instance of `ssh-agent` running on my machine at all times. The keys all get loaded the first time I log in and the agent gets accessed in every tmux window I pull up. I do type a few different passwords to load them all the first time but I'm good for the rest of the day and I don't ever notice that I have a different key for each task I do.
$ published: 2024-10-07 10:45 $
$ tags: #unix $
-- CC-BY-4.0 jecxjo 2024-10-07
Source