7

I recently discovered github-keygen, a tool that helps you set up SSH for use with GitHub. One of the things the tool does is to create a new SSH private key dedicated to GitHub exchanges; the manual claims that "this is much better than using the same SSH key to connect to multiple hosts". I don't understand why using a dedicated key for GitHub is supposed to be better. The manual justifies this practice as follows:

(If you loose [sic] that key, just revoke it in your GitHub account SSH settings, remove the key file, and re run github-keygen).

But surely this the same thing you'd do if you'd lost a non-dedicated SSH key – you'd remove it from your list of authorized keys on GitHub (and from the authorized_keys file of every other remote machine you use) and then generate a new one. What does using dedicated SSH keys for different remote hosts (like GitHub) buy you?

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
Psychonaut
  • 615
  • 4
  • 14
  • 2
    See also [What is the best practice: separate ssh-key per host and user VS one ssh-key for all hosts?](http://security.stackexchange.com/questions/40050/what-is-the-best-practice-separate-ssh-key-per-host-and-user-vs-one-ssh-key-for) – Sjoerd Jun 22 '16 at 06:51
  • That question seems to be comparing the merits of using one private SSH key per user (and copying this private key to all the clients used by that user) versus the user generating a separate SSH key on each client. However, my question is about generating a separate SSH key for use with a specific _remote_ host. (This could be done in combination with either of the two aforementioned practices.) – Psychonaut Jun 22 '16 at 07:20
  • The answer in that question applies to this question as well. It doesn't give any security benefit except for if your key is stolen, it only has access to 1 machine rather than 20. – Qwerty01 Jun 22 '16 at 21:57

2 Answers2

4

Why use dedicated SSH keys for different hosts (like GitHub)?

Answer: Revocation.

When you lose an SSH key, you have to revoke it on everything it had access to. If you use the same key on GitHub as you use to SSH in to your personal web hosting, you have to remove the key from both places. One key per service means none of your other keys are impacted by loss.

h4ckNinja
  • 3,006
  • 15
  • 24
2

The GitHub advice is possibly over stating the risk. Using the same ssh key on multiple systems has nothing like the risks associated with having the same password on multiple systems. However, there are some other factors to consider which may result in someone having more than one ssh key.

The most obvious reason to have more than one ssh key relates to your concept of identity. While most of us consider we only have a single identity, the reality is that we probably have at least two - a personal/private identity and a work identity. For most of us, our personal identity never changes, but our work/professional identity could change many times during a career. Therefore, it often makes sense to keep these two identities separate. In some organisations, you are even issued with a 'work' ssh key and when you leave the organisation, that key is revoked. If you use that key for personal purposes, you could find you have lost access to some resources or have to go through a vetting process to regain access etc.

Another reason to have more than one ssh key is to limit the value of your ssh key. This is similar to having two separate key rings - one which you hang on the hook in the hall and the other you keep in a safe under your floor. The first contains the key to low risk, frequently used resources. The second, high risk or seldom required resources. If your house is robbed, they will likely get the first, but not the second, minimising the damage.

This last item relates to key management and in my experience, the most frequent weakness/failure I see with respect to ssh keys and one of the reasons I think we have not seen wider deployment of ssh keys. I frequently encounter situations where people are using an ssh key, but have vary poor key management practices. The reality is, using ssh keys with poor key management practices is often less secure than relying on just passwords. Many users don't understand how critical it is to protect their private key and will make mistakes, like checking them into version control systems, storing them in unsecured backups, copying them to various cloud storage systems etc. Too often, I find people using ssh keys without a passphrase because it is more convenient. This is a vary bad idea. If you want convenience, then use an appropriately configured ssh agent, but make sure you have a good pass phrase (note the use of phrase rather than word!).

It is because of this key management issue I would not recommend using different keys for every site. Apart from not improving security, it adds to the key management burden - the more keys you have to manage the more likely mistakes will occur. Most people will likely want more than one key, but it would be unusual to need more than 5 and in most cases, 2 or possibly 3 would be sufficient.

Tim X
  • 3,242
  • 13
  • 13
  • For the very reason of poor key management I think multiple keys are better. If you cannot remember all the places that you use a particular key site to poor management, then you can't keep all your locations secure when one is stolen. With only one per site, you always know exactly what was impacted and how to completely revoke that key. – simpleuser Jun 24 '16 at 03:37
  • IIf you have poor key management practices, the game is over. It really doesn't matter if your managing one key badly or managing multiple keys badly. If key management is poor, then making it more complex by adding more keys is only going to make matters worse. Complexity is one of the most frequent causes of security failure. Much better to keep things as straight-forward as possible and focus on adopting good key management practices. – Tim X Jun 25 '16 at 06:49
  • I guess it depends on your definition of complexity. One key per host seems simpler to me than having to keep track of where you copied different keys to, which I bet very few people actually do. Also, finding and duplicating existing keys onto different hosts also seems to take more work that just automatically creating a new key each time a new host is accessed, especially since the generation comment on the key often contains the name of the host that generated it, meaning no additional work is needed to note that hostname. – simpleuser Jun 26 '16 at 01:04
  • Maybe we are talking at cross purposes. I don't care which hosts I copy my pub key to - it doesn't matter. If my pub key is there, then I can log in with my private key. If it isn't, then I can't. If a host which has my pub key gets compromised, I don't care - it is a pub key. So I have one private key to manage and ensure it is secure and that private key gets me into all the hosts I log into. Having a different key for each host I log into is not giving me any additional security and it now means I have more keys to manage. Why do you need to keep track of where you have copied your ke?y – Tim X Jun 26 '16 at 22:13
  • if your private key gets stolen, which is the only theft worth talking about, then you need to know all the hosts the corresponding public key was copied to so that you can remove it from all of them. Any that you forget will still be accessible to the thief. – simpleuser Jun 26 '16 at 22:32
  • 1
    I guess that may be an approach. Problem is, if you have one key stolen, your security has been compromised and you have to assume all keys are now compromised. Now instead of just replacing pub keys on remote sites, you have to generate new keys for each site. Better to just keep a list of the sites you have added your pub key to. Reality is, tto few services support ssh keys, so the number is small and easy to remember. – Tim X Jun 27 '16 at 05:50