117

So we all know how to use public key/private keys using SSH, etc. But what's the best way to use/reuse them? Should I keep them in a safe place forever? I mean, I needed a pair of keys for accessing GitHub. I created a pair from scratch and used that for some time to access GitHub. Then I formatted my HDD and lost that pair. Big deal, I created a new pair and configured GitHub to use my new pair. Or is it something that I don't want to lose?

I also needed a pair of public key/private keys to access our company systems. Our admin asked me for my public key and I generated a new pair and gave it to him. Is it generally better to create a new pair for access to different systems or is it better to have one pair and reuse it to access different systems? Similarly, is it better to create two different pairs and use one to access our companies systems from home and the other one to access the systems from work, or is it better to just have one pair and use it from both places?

Improve this question
1
  • This is not directly an answer to your question, but it is advisable to have passphrases for each key also. Ideally, separate passphrases for each key (use a password manager). The reason is as follows: If a private key is compromised (laptop got stolen, computer got hacked into), then you have some time before the key can be brute-forced and you can replace the public key on all the machines that have it, before your attacker can. Source: help.ubuntu.com/community/SSH/OpenSSH/…
    – Xandor Schiefer
    Mar 2, 2014 at 13:52

5 Answers 5

Reset to default
90

You should definitely have separate private keys per origin. Basically that means there should generally be a single copy of each private key (not counting backups). It's ok to use the same private key from closely related machine, in situations where breaking into one basically gives you access to the other (for example if they're in each other's shosts.equiv). Don't use the same private key on machines in different realms (e.g. home and work), never share a private key between two users, and never share a private key between a laptop and any other machine.

For the most part, I don't see the point in having different private keys for different destinations. If a private key is compromised, all other private keys stored in the same directory will surely be compromised as well, so there would be added complication for no security benefit.

If you follow these principles, each key pair identifies one (machine, user) pair, which makes authorization management easier.

I can think of two exceptions to the general rule of a single private key per origin:

  • If you have a passwordless key that gives access only to a specific command on a specific machine (e.g. an automated backup or notification mechanism), that key must be different from the general shell access key.
  • If some machines are intermittently connected, you might have an old private key alongside a new private key, until you get around to finish deploying the new key.
Improve this answer
9
  • 5
    This is how I've always used my keypair. I didn't understand why GitHub was advocating generating a new keypair in their setup instructions. I ignored that and used my standard keypair. I assume they are being conservative.
    – user25884
    Nov 23, 2011 at 16:14
  • Ok, so you say "Dont use the same private key on machines in different realms" but what if DNS resolves a given host name to either machine depending on your location? Without sharing the private key I get warnings or failures when I try to ssh or rsync to that host name because ssh gets confused at having two separate keys for the same host name.
    – Michael
    Apr 18, 2018 at 18:02
  • @Michael I don't understand what problem you might have with user keys in the scenario you describe, which is what this thread is about. SSH would get confused about host keys, but as a user what you see is the host's public key, not the host's private key, and sharing a host's private key is dangerous — I'd only recommend that if the hosts are completely equivalent (redundancy in case one of them fails), and probably not even then.
    – Gilles 'SO- stop being evil'
    Apr 18, 2018 at 18:30
  • Ah, ok. Seems like there is not a lot of clear distinction between the two, and it is just assumed that you know which one is being talked about.
    – Michael
    Apr 18, 2018 at 18:42
  • 1
    @JSBach Having separate keys per realm allows you to define finer-grained permissions (the key stored on low-security realm A is allowed for used between machines of A, but logging into B requires a stronger authentication factor) and allows you to revoke them separately (realm A got compromised, but I can still log into C from B). SSO is the case where you log into the highest-security system, and then you can log in elsewhere. I don't know what risks they see in having multiple keys per user. This would be a topic for Information Security.
    – Gilles 'SO- stop being evil'
    Jun 6, 2018 at 12:35
4

I don't know what's the best way but I can tell which my way is.

As a sysadmin I use a different key to access each server/service as root. This way, if a key is lost or compromised I limit the risk to one single server and I don't need to update all my services with brand new keys.

Speaking of users, I use a different key for each one of them. With that key the user can access the service he needs as an unprivileged user. This way, I can easily grant or revoke access to single services to each user. In case the user looses his key I can delete it from all the services and limit the risk of unauthorized access.

Improve this answer
1
  • +1 I´m going to talk with my boss about a new key usage policy ;-) per server/service sounds even more secure than just per network
    – Diskilla
    Sep 16, 2010 at 18:14
3

I believe you could use the private key anywhere as long as you put a passphrase on it, meaning to say if you would like to share your private key with few machines, say laptop 1, 2, desktop 1, 2, should be fine.

From my experience, my main machine is my desktop that I does most of my job with its powerful processor, but at times I need to use my laptop on mobile, troubleshooting in data center and stuff, so, I could still login to any hosts that I have my public key resides in.

Improve this answer
3
  • 1
    Read the best answer here. You're doing it wrong. It's not that you can't do it that way but you shouldn't.
    – PhilT
    Jul 14, 2013 at 5:52
  • 3
    Can't see why all the downvotes. University networks (for example) often have a networked home directory, so the same private key gets used everywhere by a user, even on laptops you are given. As long as you don't copy it unencrypted over the internet, then I think it's fine if you understand the risk. Bloody more convenient that way too, not having to add your public key to 2,000 different places just because you logged into a different machine.
    – Asfand Qazi
    Apr 19, 2017 at 10:27
  • Upvoted because you shouldn't be losing rep for this answer. It's personal preference, obviously using a separate key per service and machine ultimately gives you more control, but sometimes it's just a waste of time depending on your use case.
    – Daniel Dewhurst
    Jul 9, 2018 at 8:41
0

At my company we use these Keys user specific. That means case two. The user has his own key and this one is used for every machine he uses to connect to the company system. my opinion is to use one key for one system. That means you use this key on every machine you need to connect to the specific networks. For your case that would be one key for GitHub and one key for the company system. So, if your admin asks you again, I would give him the same key as last time. not a new one. But, I don´t know if there is a common usage policy for these keys and I am doing it wrong ever since. That sure is possible ;-)

Improve this answer
0

The public key you generated is for everyone. It will allow them to a) check authentizity b) encrypt for you

The private key is, well, private. It is only for you. And it’s the key you should backup somewhere, in a secure place. You can also encrypt it with a secure password if you save it on an USB stick for example.

The public key is your identity to others. So there’s no problem / it’s better to use one key pair for everything, at least where you don’t want to use an explicit new identity, so others won’t know it’s you.

Improve this answer
1
  • 3
    Thanks, but your answer is, mostly, unrelated to my question. See @Diskilla's answer.
    – Behrang Saeedzadeh
    Sep 16, 2010 at 14:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .