Is it safe to generate a public/private key pair on the server, add the public key to the authorized_keys list, and then copy the private key to each client, as described here (http://www.rebol.com/docs/ssh-auto-login.html) Assuming you maintain permanent control over each client? (i.e. same user, many computers).

Typical procedure is to generate the public/private key pair on the client, and then add the client's public key to the authorized_keys list on the server as described here (http://www.linuxproblem.org/art_9.html). With this method, if you have several client computers, each much must be concatenated to the authorized_keys list and maintained over time.

2 Answers 2


Congratulations, you've found an Internet tutorial with bad advice.

The problem with using a single keypair for multiple computers occurs when any one of the computers is compromised. Then you have no choice but to revoke the keypair everywhere and rekey every single computer which was using that keypair. You should always use unique keypairs per machine and per user, to limit the damage that a compromised key can do.

As for that tutorial, it's amazingly bad advice to generate the keypair on the server and copy the private key to the client. This is entirely backward. Instead, the keypair should be generated on the client and the public key copied to the server. There is even a helper script ssh-copy-id which does exactly this, and along the way makes sure all permissions are correct, the client gets the server's host key, etc.

There may indeed be situations where you want to centrally manage users' identity keys, e.g. for automated scripts, but in this case you really should do this from a third host, or ideally from a configuration management system such as puppet.

  • 2
    Additionally, the user of the client machine have to remember that this particular key cannot safely be used for any other purposes, as you can't know where the private key has been. If you know the secret key was generated on the client and never left the client, it is generally safe to use the same key to log in to different systems.
    – kasperd
    Mar 27, 2015 at 0:16
  • 7
    An analogy with sharing needles came to mind, but I really wasn't sure I wanted to go quite that far... Mar 27, 2015 at 0:21
  • Not sure how you'd get the asymmetrical part into that analogy.
    – kasperd
    Mar 27, 2015 at 0:23
  • 1
    Well... depends on which end of the needle you are. Mar 27, 2015 at 2:10

The biggest problem with the protocol described in that tutorial is that it doesn't specify how you "download the private key to the client machine" in a secure manner (i.e., that prevents eavesdropping). If you don't already have a secure channel, the key will presumably be transferred in clear over the Internet (HTTP, FTP, email, etc). You can use HTTPS, but if you don't have a real certificate, it can be MITM'd to sniff the key. Just do it the way you're supposed to; generate the keypair on the client machine, transfer the public key to the server, and don't forget to verify a checksum of the file to make sure it hasn't been modified in transfer.

You must log in to answer this question.

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