143

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

Update:

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

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 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
    Thank you for so rich answer! Do you know a good article about private key encryption? Does this fit enough [martin.kleppmann.com/2013/05/24/…? – static Aug 5 '13 at 13:43
  • 3
    That'll do; similar information here. Use ssh-keygen -p to re-encrypt existing keys. (Docs) – tylerl Aug 5 '13 at 16:58
  • "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 7 '16 at 7:53
  • 1
    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 7 '16 at 19:48
  • 2
    @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 7 '16 at 19:55
12

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.

  • This should be the accepted answer as it explicitly answers the question very clearly. – jdk1.0 Jul 17 at 12:58
5

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.

  • 9
    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
  • 1
    @Navin What's wrong with that? – Asfand Qazi May 3 '17 at 9:01
  • 1
    @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 3 '17 at 10:29
  • 4
    I see. You realise you have just deanonymized yourself by posted two comments with the same account? I hope they don't catch you. – Asfand Qazi May 10 '17 at 13:09
  • Busted. @Navin == Asfand Qazi!! – Timothy L.J. Stewart Jul 29 '18 at 1:54
2

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?

  • 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 4 '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 – enigma Aug 4 '13 at 23:30
2

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.

  • 2
    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 0: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
  • 2
    @Kris. There is a benefit to having multiple keys on one machine, IFF 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 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 at 20:41
1

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.

  • Thats a great point, insider threat is the greater threat to an organization. – Timothy L.J. Stewart Jul 29 '18 at 1:59
  • 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 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 at 21:09
1

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.

  • Scenario 1: couldn't one configure the keys per site using an SSH config file? – jdk1.0 Jul 17 at 13:10
  • @jdk1.0 That is a good idea I hadn't thought of. I think it would probably also work with Putty. – Kevin Keane Aug 5 at 20:29
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.