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.
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.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.