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:


in comparison to separate ssh-keys:

... etc.

8 Answers 8


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.

  • 6
    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
    Commented Aug 5, 2013 at 13:43
  • 8
    That'll do; similar information here. Use ssh-keygen -p to re-encrypt existing keys. (Docs)
    – tylerl
    Commented Aug 5, 2013 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
    Commented Jun 7, 2016 at 7: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
    Commented Jun 7, 2016 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
    Commented Jun 7, 2016 at 19:55

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, some (or many) people still focus more on the information in brackets: "(empty for no passphrase)", and follow that suggestion.

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


The following table ranks the relative security of each option (where a larger number means more secure):

Security SSH Key pairs Passphrase
1 One No
1 Multiple No
2 One Yes
2 Multiple All same
3 Multiple All different

Without a passphrase, if an attacker breaks into our system, they can get all of our private-keys and config, as well as the authentication of remote servers. So in this situation, One key-pair and Multiple key-pairs are the same. The most secure way is to use different passphrases for different ssh key-pairs.


But, there's a tradeoff—using more key-pairs and passphrases is more inconvenient. This is reflected in the following table (the larger the number, the better):

Convenience Security SSH Key pairs Passphrase
5 1 One No
4 1 Multiple No
3 2 One Yes
2 2 Multiple All same
1 3 Multiple All different

As we generally want to balance security and convenience, we can multiply the two scores. So One SSH key-pair with passphrase could be the best option for the average person, but it depends on the level of security you're after.


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.

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

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.

  • 16
    This is wrong. Using the same key to login to 2 servers/accounts reveals that both users are probably the same person.
    – Navin
    Commented Nov 10, 2015 at 20:24
  • 2
    @Navin What's wrong with that? Commented May 3, 2017 at 9:01
  • 5
    @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
    Commented May 3, 2017 at 10:29

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.

  • The landscape has changed yet again. If you use the hardware token for FIDO sk keys, you can nominally have as many as you want. (If you choose to use resident keys, it's still ~25 for recent models.) Commented Jul 1 at 14:20

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.

  • 5
    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 Commented Jun 23, 2016 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
    Commented Sep 23, 2016 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
    Commented Jan 12, 2017 at 13:23
  • 5
    @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
    Commented Jun 12, 2017 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. Commented Jan 22, 2019 at 20:41

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. Commented Jul 29, 2018 at 1: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. Commented Jan 22, 2019 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. Commented Jan 22, 2019 at 21:09

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.

You must log in to answer this question.

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