1

I have one machine say source1 and there is passwordless ssh already set to more than 100 server say remote1, remote2, ...remote100.

Now I need to set similar setup of passwordless ssh on another server source2 and I dont want to copy the public key of source2 to authorized_keys file of all hundred server.

Can I use the private key of server source1 to set similar setup on source2? How to achieve that? I heard of ssh-agent is one of the way but could not understand much on the steps.

  • client authentication is to authenticate a user, not a machine. – Stéphane Chazelas Aug 15 '14 at 12:32
  • yes..I am using root user – Venom Aug 15 '14 at 12:33
  • The setting up can be handled automatically with a simple loop. for remote in $(seq 100); do cat public_key.pub | ssh "remote$remote" tee -a ~/.ssh/authorized_keys; done. Unless all your remote use the same authorized_keys file, you'll have to edit all of them. – John WH Smith Aug 15 '14 at 12:34
  • @JohnWHSmith, ssh "$remote" 'cat >> .ssh/authorized_keys' < public_key.pub. Otherwise you'll overwrite the authorized_keys (and ~ on the remote host may not be the same as on the local host). – Stéphane Chazelas Aug 15 '14 at 12:36
  • @StéphaneChazelas Added -a just now and posted an slightly more detailed answer, thank you. – John WH Smith Aug 15 '14 at 12:37
1

If all your remotes have their own root user (that is, different /root directories), with their own authorized_keys file, you'll need to edit all of them all in order to add a new key:

for remote in $(seq 100); do 
    cat public_key.pub | ssh "remote$remote" tee -a .ssh/authorized_keys
done

However, you could also send your source1's private key to source2. This way, both machines will use the same key pair (which is already registered by all the remotes). I don't think this could create any kind of conflicts, yet having two keys seems more natural to me. Fact is, since all your machines are probably on the same network, and managed by the same user, having one key compromised would probably breach the whole system. Therefore, having two wouldn't bring that much more security (since one is enough to become root somewhere).

  • The ~ is expanded on the local machine, you want it expanded on the remote machine (assuming the login shell of the remote user supports it). But the remote command's cwd normally starts in the user's home directory so you can do tee -a .ssh/authorized_keys or 'cat >> .ssh/authorized_keys' – Stéphane Chazelas Aug 15 '14 at 12:39
  • Since the OP is setting up a root key pair, ~ would be expanded to /root anyway. I'll edit my answer, thank you. – John WH Smith Aug 15 '14 at 12:41
  • You're right; using one key would not create conflicts, and having two keys is no more safe against compromise than having one key on two machines. But if source1's key did get compromised, having different keys could help with cleanup afterwards since you wouldn't have to replace source2's key (and source3's, etc). With careful logging, you could also tell which key (and therefore which machine) was compromised: unix.stackexchange.com/questions/15575 – Jander Aug 16 '14 at 1:41
0

The approach to take depends on the specific scenario. It would be nicest if there already is a key that exists in the user’s authorized_keys on all of the servers that can be used to authenticate when adding the new key to the remote hosts, because otherwise you have to type in your password for each host.

The simplest way to automate copying a ssh key to a remote machine is using ssh-copy-id, and if you have servers called remote1 through remote100 it could be done using something like the following:

for server in $(seq -f 'remote%.0f' 1 100); do
    ssh-copy-id -i ~/.ssh/id_rsa "$server"
done

Which would automatically take the public key for id_rsa, ssh into all of the servers in sequence, and add the public key to authorized_keys. If this is the only key you would have on the servers you will be prompted for your password to add them though, since the ssh-copy-id program needs to actually ssh into the servers.

One way to automate it even further would be to use something like expect to automate logging in with a password since OpenSSH’s ssh client doesn’t have a command-line option to specify the password, or alternatively by using a wrapper like sshpass.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.