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.
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.
ssh-keygen -p to re-encrypt existing keys. (Docs)
– tylerl
Aug 05 '13 at 16:58
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.
config file?
– SO_fix_the_vote_sorting_bug
Jul 17 '19 at 13:10
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.
Since the question was asked, the landscape has changed considerably. Today, there are two points that favor a single SSH key for all hosts.
Of course, this does not invalidate the other considerations mentioned in earlier answers.
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.)
– Michael come lately
Jul 01 '24 at 14:20
The main benefit of separate keys is what happens in the worst-case scenario: someone gets your private key.
So--most secure? Unique keys for each host.
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
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-ioption. An alternative is to adjust theMaxAuthTriessession on the server, but this is not a full solution and it is undesirable to increase the number of attempts for password authentication.
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.