A lot of public git repos are configured around the use of SSH keys for authentication. It’s a good idea to use different keys for each server.
Doing this requires two steps:
- create a unique key for the server (and submit it as normal)
- configure your SSH client to use the new key just for that server
Creating the key is easy (Linux/Mac – sorry, Windows users) – ssh-keygen -f ~/.ssh/site_key (rename site_key as appropriate)
Then, you need to add a section like this in your ~/.ssh/config file:
Host site_name
IdentityFile ~/.ssh/site_key
(Again, change site to whatever is appropriate)
Congrats! You’ve now got a unique key just for one site – this means if they happen to get compromised, all you need to do is regenerate the key, and away you go.
(Of course, you may want to use passphrases, and other appropriate measures, on your end – but that’s good advice anyway)
Share this:
Software is too expensive to build cheaply.... 
“this means if they happen to get compromised, all you need to do is regenerate the key, and away you go”
This actually seems like generally good advice for all ssh logins.
I agree that in an absolute sense this increases security, but I’m not sure the gains are worth the extra work and ongoing maintenance.
Your reasoning for developing and using this method seems to be motivated by a worry that someone will compromise your ssh key. However, in order to compromise your key they would have to get a copy of your private key. If they’ve managed to get a copy of one private key they will likely be able to grab all the keys at the same time.
If an attacker compromises the git server you’re connecting to they can only get a copy of your public key (presuming you have sensibly turned off agent forwarding for this connection). If they get a copy of your public key so what? There’s no attack vector there, the system is designed in such a way that an attacker can know the public key and the system remains secure.
If you know for a fact that they have compromised one of your ssh keys by acquiring the private key, you will have no choice but to regenerate all of your keys under the assumption that if an attacker could grab one they could grab all of them. This actually increases the amount of work required to recover from a security breach.
So you are essentially increasing the amount of work done in the normal case (regenerating all keys because a compromise of one is a potential compromise of all) to optimize for a corner case (regenerating a single key when you somehow know that only one key was compromised.)
Is there something I’m missing?
Well, it depends how paranoid you are. SSH keys aren’t perfect – they can and have been cracked in the past. They work great for encrypting communication – cracking them in realtime is beyond anyone except maybe the NSA – but as a permanent security method, they’re vulnerable. They’re not like PGP keys or SSL certificates – SSH keys are intended to be a shared secret.
As for the ongoing maintenance issue – yes, if your box gets compromised, you need to regenerate and resubmit your keys. Regenerating is trivial – a simple
'for key in *_key; do ... done‘, and your keys are refreshed. Resubmitting them is more likely to be a pain, but it’s no different – in concept – to changing your passwords on multiple sites, which you should also do if you are compromised on your end. Also the amount of work required to resubmit your keys is identical if you’ve got one master key or one key per server.You can use a different passphrase for each private key however, which gives you extra time and relief after the symmetrically-encrypted private keys have been compromised.
I do see the benefit of generating one key pair per server.