214

Is it better to create a separate SSH key for each host and user or just using the id_rsa key for all hosts to authenticate? Could one id_rsa be malpractice for the privacy/anonymity policies?

having one ssh-key for all hosts:

~/.ssh/id_rsa
~/.ssh/id_rsa.pub

in comparison to separate ssh-keys:

~/.ssh/user1_host1
~/.ssh/user1_host1.pub
~/.ssh/user2_host1
~/.ssh/user2_host1.pub
~/.ssh/user3_host2
~/.ssh/user3_host2.pub
~/.ssh/user4_host3
~/.ssh/user4_host3.pub
... etc.
schroeder
  • 123,438
  • 55
  • 284
  • 319
static
  • 2,239
  • 2
  • 12
  • 7
  • 2
    related: ["Reusing Private/Public Keys"](http://security.stackexchange.com/questions/10203/reusing-private-public-keys) – David Cary Sep 22 '14 at 22:12

9 Answers9

225

A private key corresponds to a single "identity" for a given user, whatever that means to you. If, to you, an "identity" is a single person, or a single person on a single machine, or perhaps a single instance of an application running on a single machine. The level of granularity is up to you.

As far as security is concerned, you don't compromise your key in any way[1] by using it to log in on a machine (as you would by using a password), so having separate keys for separate destinations doesn't make you any more safe from an authentication/security perspective.

Though having the same key authorized for multiple machines does prove that the same key-holder has access to both machines from a forensic perspective. Typically that's not an issue, but it's worth pointing out.

Also, the more places a single key is authorized, the more valuable that key becomes. If that key gets compromised, more targets are put at risk.

Also, the more places the private key is stored (say, your work computer, your laptop, and your backup storage, for example), the more places there are for an attacker to go to grab a copy. So that's worth considering as well.

As for universally-applicable guidelines on how to run your security: there are none. The more additional security you add, the more convenience you give up. The one piece of advice I can give categorically is this: keep your private key encrypted. The added security there is pretty significant.

[1]: There's one important way in which authorizing the same SSH key in different security contexts could be a problem, and that issue has to do with agent forwarding. The constraints and caveats around safely using agent forwarding is outside the scope of this question though.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • 5
    Thank you for so rich answer! Do you know a good article about private key encryption? Does this fit enough [http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html]? – static Aug 05 '13 at 13:43
  • 6
    That'll do; [similar information here](http://security.stackexchange.com/a/39293/2264). Use `ssh-keygen -p` to re-encrypt existing keys. ([Docs](http://linux.die.net/man/1/ssh-keygen)) – tylerl Aug 05 '13 at 16:58
  • 1
    "so having separate keys for separate destinations doesn't make you any more safe from an authentication/security perspective" isn't that like saying "using separate passwords for your website logins isn't more secure than using a different password for each website"? – DBedrenko Jun 07 '16 at 07:53
  • 2
    PastaFeline, I would think the key difference (see what I did there?) is that the secret bits (the private key) for SSH never leave the client machine, while the secret bits (the password) or a hash of them are transmitted to the remote machine for password auth. If a user's password is weak it's vulnerable to brute-force cracking (see Rainbow Tables) even if all you have is the hash. – Scott Jun 07 '16 at 19:48
  • 3
    @SpaghettiCat no, what I'm saying is that using a single ssh key across multiple destinations does not give any one destination enough information to impersonate you to any of the others. – tylerl Jun 07 '16 at 19:55
  • Throwing my two cents in. I do use a different key for each host. I work for multiple clients and from multiple machines. As such, I have to store my (encrypted) private key in some (encrypted) cloud storage, in case I need to access a host from another machine. If I have to risk taking the key off my machine, I'd rather it was for one host and not for everything I have permissions to access. It's a fair bit of hassle but I believe it is safer than moving a key with super privileges. – freethebees Feb 07 '20 at 08:38
38

I think this question can be considered from two different angles: security and convenience.

When we create a SSH key pair, we are asked for providing a passphrase to add a more layer to protect the private-key, as following:

$ ssh-keygen -t rsa -b 4096 -C 'With_OR_Without_Passwd'
Generating public/private rsa key pair.
Enter file in which to save the key (/Your/HomeDir/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):

Although there is an explicit prompt asking for passphrase, but some (or many) people still focus more on the information in brackets: (empty for no passphrase), and following that suggestion.

Combining whether or not using multiple SSH key pairs and whether or not enter additional passwd, we have at least four ways to go. And let's assume all key-pairs and the config file are stored in ~/.ssh/.

Now let't consider security first.

The following table gives a simple rank about security (larger number means more secure):

Security     Ways to go
   1         One   SSH key-pair  (NO passwd)
   1         Multi SSH key-pairs (NO passwd)
   2         One   SSH key-pair  (WITH passwd)
   2         Multi SSH key-pairs (WITH passwd) (SAME passwd)
   3         Multi SSH key-pairs (WITH passwd) (DIFF passwds)

Without passwd, if our system is intruded by someone, then the breaker can get all of our private-keys and config, also the authentication of remote servers. So in this situation, One key-pair and Multi key-pairs are the same. The most secure way is to use different passwds for different ssh key-pairs.

Then let't think about convenience.

But more key-pairs and more passwds also make our life less convenient, the following table gives a simple rank about security (larger number means more secure):

Convenient  Security  Ways to go
   5           1      One   SSH key-pair  (NO passwd)
   4           2      One   SSH key-pair  (WITH passwd)
   3           1      Multi SSH key-pairs (NO passwd)
   2           2      Multi SSH key-pairs (WITH passwd) (SAME passwd)
   1           3      Multi SSH key-pairs (WITH passwd) (DIFF passwds)

So, in general situation, if we have to trade off with security and convenience at the same time, we can multiply the two scores, and maybe One SSH key-pair (WITH passwd) is the good one to choose.

YaOzI
  • 481
  • 4
  • 5
6

As a rule of thumb, I agree with the other answers - a single key per user is often the most practical way to go. It is not, however, good as a one-size-fits-all approach.

Here are a few additional considerations.

  • If you are using an SSH agent, more than three or four keys become problematic, because when connecting to a server, your SSH client may try one of the stored keys after the other. That may lead to several failed logons on the server side, and you may actually find that your account is locked out before SSH even tries the correct key. This aspect favors the one-key-per-user approach.

  • If you are serving multiple independent entities (such as a consultant serving multiple clients), consider a separate SSH key for each client. It is not unheard of that when the relationship ends, the client may demand handing over all passwords and SSH keys. Sometimes, explaining why that's not a good idea works, but if the client gets something like a court order, you may have a problem.

  • If your SSH private key is compromised, you may have to change it on many systems. Do you even remember every single system you ever, in the last ten years, set up with that SSH key? Would you remember to remove your compromised SSH key from Github? Or from the router in some closet in the office a couple states away that you remote-manage? What about systems that you can't touch any more because you no longer work for that particular client?

In the end, it comes down to understanding the implications of the two approaches, and balancing them against the particular concerns of your situation.

Kevin Keane
  • 1,009
  • 7
  • 8
6

You only need one key as the key belongs to your user.

There is no need (and no improvement in security) by having one key per host.

As long as your private key is kept private you can go with this single key and use it to authenticate yourself against multiple hosts.

Community
  • 1
Uwe Plonus
  • 2,267
  • 12
  • 14
  • 13
    This is wrong. Using the same key to login to 2 servers/accounts reveals that both users are probably the same person. – Navin Nov 10 '15 at 20:24
  • 2
    @Navin What's wrong with that? – Asfand Qazi May 03 '17 at 09:01
  • 3
    @AsfandYarQazi If you use the same key on different sites, you can easily deanonymize yourself. Go ahead and google "We kill people based on metadata". – Navin May 03 '17 at 10:29
3

The main benefit of separate keys is what happens in the worst-case scenario: someone gets your private key.

  1. SAME key on all hosts: The bad guys now have access to everything.
  2. DIFFERENT key on each host: The bad guys only have access to one thing.

So--most secure? Unique keys for each host.

James
  • 131
  • 2
  • 3
    If the attacker has access to the folder from the question, not only he has access to your private key, but also a list of usernames and hosts those keys work with – German Rumm Jun 23 '16 at 00:21
  • yes; people have to actually have to be productive with security measurements. If you increase the burden of use then you can also increase the probability of an exploit. – Tim Harper Sep 23 '16 at 21:48
  • On a typical machine, say an OSX computer, the keys will typically reside in ~/.ssh/ If an attacker has access to one key, it probably means they have access to all of them. In that sense, there is no benefit to have multiple keys on one machine, however, it is probably prudent to have individual keys for each client machine, all registered a a certain endpoint (say GitHub)? Or am I missing something? – Kris Jan 12 '17 at 13:23
  • 3
    @Kris. There is a benefit to having multiple keys on one machine, [IFF](https://en.wikipedia.org/wiki/If_and_only_if) the keys are protected by a passphrase and the passphrases differ. If an attacker gets access to your private keys, he will still have to crack the passphrase for each of them. It all depends on the threat level and the effort you are willing to expend. Also see https://superuser.com/a/121348/478867 – NZD Jun 12 '17 at 23:57
  • @NZD It's not IFF. There is still a benefit even if the passphrases are the same. For example, your laptop gets stolen while one of the keys is decrypted due to being in use. The attacker gets the one key, but the fact that the passphrases are the same doesn't help him get access to the others. – Jon Bentley Jan 22 '19 at 20:41
  • @JonBentley Yes, in this case you are right. My scenario is, if a (single) passphrase is compromised, the attacker will only gain access to to one set of keys and not all; damage will be limited. Again, it is all down to how paranoid you are and what is at stake. You could also have different keys for work and private and are forced to hand over your work keys and passphrase when you leave the company (you could remove or change the passphrase in that case as well). So, I guess, every situation is different and requires a security and safety analysis. There is no panacea. – NZD Jan 22 '19 at 22:28
  • But if you have one key-pair `A` on a work laptop and one pair `B` on a private laptop, (one for github and one for bitbucket, e.g.), isn't that more secure than a single key-pair even if the passwords are the same for `A` and `B`? In the scenario an attacker only breaks into one machine and gets the private key. – SO_fix_the_vote_sorting_bug Jul 17 '19 at 13:07
3

What is the best practice: separate ssh-key per host and user VS one ssh-key for all hosts?

I dont know if i got your question right what do you mean by "key"? are you referring to asymmetric crypto?

when using asymmetric crypto you have a private and public key pair. The public key of each user is stored on the ssh-server (host). This allows to authenticate the user because for each public key there should be only one private key.

enter image description here

what do you mean by having one ssh-key for all hosts?

enigma
  • 1,798
  • 1
  • 11
  • 14
  • I already saw the image, but I'm interesting in details of the transition from step "Remote SSH server configured with "Public Key"" to "Private and Public Key Pairs MATCHED?" – static Aug 04 '13 at 23:20
  • if you are just interested in the transition from "Remote SSH server configured with "Public Key"" to "Private and Public Key Pairs MATCHED?" then take a look [this](http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch03_04.htm) – enigma Aug 04 '13 at 23:30
2

This may come a little late, but i think it is worth mentioning: From a security and convenience perspective, when managing human users, it is desirable to have one key per user.

The advantages come when you need to revoke access to a single user.

Lets say you are using one key for all users and without password (or with same password). You may disable the user in the server (the "account"), but all the human needs is the user and the key to gain access. He/she already has the key as it is a file, you cant control this, and then he just needs a username (perhaps the user (accounts) are made with an standard algorithm (e.g. first letter of name + lastname)) to gain access as another user. Then, for security reasons, you would have to create a new key-pair (and deliver it to the users) and disable the old key-pair.

It is much simpler if you have one key per user, as you just disable the user (and the key if you want).

When managing systems or servers that handle sensitive data, where the user pool is variable (and it almost certainly will be, what varies is the rotation speed), this becomes a good practice in terms of security and convenience.

Manuel Herrera
  • 21
  • 2
  • Thats a great point, insider threat is the greater threat to an organization. – Timothy L.J. Stewart Jul 29 '18 at 01:59
  • 1
    I believe you have misunderstood the question. The OP is not comparing one key per user vs. one key for all users. He is comparing one key per user vs. multiple keys *per user* per host. – Jon Bentley Jan 22 '19 at 20:38
  • I believe you are right, although my answer was prior to the update. That said, the OP question is just a matter of governance, not of best practice. – Manuel Herrera Jan 22 '19 at 21:09
1

Since the question was asked, the landscape has changed considerably. Today, there are two points that favor a single SSH key for all hosts.

  • Hardware keys are getting more popular. At least the arguably most popular brand, Yubikey, only supports a single SSH key.
  • If you are using an LDAP server for authentication, you can add an LDAP schama to store an SSH public key in LDAP, instead of adding it to each host individually. Some other IDM solutions may also offer similar features.

Of course, this does not invalidate the other considerations mentioned in earlier answers.

Kevin Keane
  • 1,009
  • 7
  • 8
1

If you are using OpenSSH server, then be aware that there is a bug that can prevent authorization if there are more than 5 keys in the default .ssh directory. Here is the explanation directly from ssh.com

OpenSSH's limitation on the number of private keys

The OpenSSH server has a feature (I would call it a bug) that it counts testing whether a particular key can be used for authentication as an authentication attempt. This has the consequence that if the user has more than five keys in .ssh, only some of them work. This often causes key-based authentication to fail and is often difficult for users to figure out. The way around this is to explicitly specify the private key to use using the -i option. An alternative is to adjust the MaxAuthTries session on the server, but this is not a full solution and it is undesirable to increase the number of attempts for password authentication.

Glorfindel
  • 2,235
  • 6
  • 18
  • 30
Danny T
  • 11
  • 1