Best Practice: ”separate ssh-key per host and user“ vs. ”one ssh-key for all hosts“

  • 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.
    
  • tylerl

    tylerl Correct answer

    8 years ago

    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.

    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]?

    That'll do; similar information here. Use `ssh-keygen -p` to re-encrypt existing keys. (Docs)

    "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"?

    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.

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

    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.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM