Git Tip – Use different SSH keys per server

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)

Unknown's avatar

Author: Robert Watkins

My name is Robert Watkins. I am a software developer and have been for over 20 years now. I currently work for people, but my opinions here are in no way endorsed by them (which is cool; their opinions aren’t endorsed by me either). My main professional interests are in Java development, using Agile methods, with a historical focus on building web based applications. I’m also a Mac-fan and love my iPhone, which I’m currently learning how to code for. I live and work in Brisbane, Australia, but I grew up in the Northern Territory, and still find Brisbane too cold (after 22 years here). I’m married, with two children and one cat. My politics are socialist in tendency, my religious affiliation is atheist (aka “none of the above”), my attitude is condescending and my moral standing is lying down.

4 thoughts on “Git Tip – Use different SSH keys per server”

  1. “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.

    Reply

  2. 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?

    Reply

    1. 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.

      Reply

    2. 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.

      Reply

Leave a comment