Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
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)
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/.
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.
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.
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?
Jul 17, 2019 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.
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.
what do you mean by having one ssh-key for all hosts?
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.
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.
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.
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.
