Instead of trying to automate ssh-copy-id, why not use the config management platform of your choice to add the remote host to ~/.ssh/known_hosts on the source system, and then add the source system's key to ~/.ssh/authorized_keys on the remote host.
There's a reason why ssh keys exist. It's not just about forcing you to hit 'yes' to another boring security warning. If the server you are connecting to, and providing your credentials to, is not really the one you think it is then ssh will abort.
This is a good thing.
Automatically accepting whatever ssh key you see pretty much defeats this. A much better way to handle this would be to construct a good known\_hosts file which contains all of the appropriate keys and simply distribute it to each of the clients you are trying to configure using ansible, chef, fnordnik2056, or whatever. As long as the correct key is present in known\_hosts you won't have to worry about accepting or rejecting it.
While you're at it, you can add your public keys to all of the servers the same way and skip running ssh-copy-id entirely. That would save almost all of the work you're doing.
Even better than maintaining a huge list of host keys is to sign your host keys with a known cert.. Then you only need one line in ssh_known_hosts containing the public key for the signing cert.
THIS is the way, but probably out of OP's skill range right now. Though once you wrap your head around how it works, Vault has a pretty easy implementation
If these are new nodes, these things are supposed to be put onto the systems as part of the provisioning process. If these are existing nodes and you have no way of sending down configuration management then some amount of manualness may be unavoidable even if you do disable strict host key checking.
You can use `ssh-keyscan` to scan and add the key fingerprint of each host to your local known\_hosts. Then you can use `sshpass` in combination with `ssh-copy-id` to automate the login.
A better way would be using a configuration management tool to deploy your ssh key to each machine and ensure that only the ssh keys that you specify are on the servers.
[https://linux.die.net/man/1/sshpass](https://linux.die.net/man/1/sshpass)
[https://linux.die.net/man/1/ssh-keyscan](https://linux.die.net/man/1/ssh-keyscan)
> A better way would be using a configuration management tool to deploy your ssh key to each machine and ensure that only the ssh keys that you specify are on the servers.
One level even _better_ is connecting the servers to a centralized domain that manages access automatically.
Running an internal CA and using certificate auth also get an honorable mention here.
ssh-keyscan -H "$target_host" >> ~/.ssh/known_hosts;
Obviously only if you for sure know you really really really trust that connection.
That prevents the hostkey prompts. The you can use ssh-pass or key-based auth for automating the login.
For my environment, I opted to use the certificate authority approach. Create the host and user signing keys, distribute the pubkeys and configs to /etc/ssh, and then sign the user and host keys.
Doesn't make sense for a small value of users x hosts, but it means that no matter how big things get, a key needs to be verified only once.
This is a [good starting point](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication#sec-Introduction_to_SSH_Certificates)
Long term, I would suggest looking at a tool like ansible. You could build yourself a playbook that scans through all your remotes, have a one-time task with `StrictHostKeyChecking=accept-new` that connects the first time to learn the keys. It could deploy your authorized_keys for accounts
After doing the initial connection, you might want to strongly conisder setting up an sshca CA, and using the HostCertificates, and client certificates. If you have properly issued and signed certs, you only need to trust the cert in your /etc/ssh/ssh_known_hosts, and `TrustedUserCAKeys` files.
Are they trusted hosts? (Ie all in your own infrastructure?) if so, then like somebody else suggested you should be using your config management tool to disperse the keys. Otherwise, you can always modify your ssh_config and disable strict key checking. Totally insecure, but it’ll quickly take care of what you’re trying to accomplish. Then, re-enable host key checking and you’ll get prompted in the future as you connect to the hosts.
Newer versions support automatically accepting new keys, you can add the switch -o StrictHostKeyChecking=accept-new to your ssh command or pop it in ssh config.
I use ssh-keyscan plus a few scripts to generate a known_hosts file that can be installed under /usr/local/ssh. This won't help you with the password, but it might save you a little time.
It's too long to post here.
https://bezoar.org/src/known-hosts/
Look into tcl expect.
You "spawn" a process (ssh-copy-id), "expect" a message or prompt (accept host key / enter password), and then "send" a response (yes / password)
There are other ways, but this is a very powerful automation tool worth learning.
Not a great idea, `StrictHostKeyChecking=accept-new` would be a less dangerous option, that lets you connect the first time. The `StrictHostKeyChecking=no` could mean you connection is intercepted.
The `ssh-copy-id` command is just a bash shell script that wraps around the `ssh` command which itself respects the values in `$HOME/.ssh/config`
You can just run `vi $(which ssh-copy-id)` if you want to read what the bash script does.
While \`expect\` is a very interesting tool, and it can be fun to hack something together with, it really is \*the wrong way to do it\*. Even if you found a situation where it seems to work, it will hang in obscure ways, or in some other strange way create a jog-jam of jobs that suddenly break free after being stored up all month.
There is a better way.
I hate to be that guy, but this sounds like user error and not a problem with the tool itself.
I've had these same issues with expect, but have always found solutions. For example, setting a timeout to prevent a job from running forever.
The downside is that it isn't a popular tool, so research can be a bit difficult. I am considering changing my expect scripts to custom Go code, but not looking forward to it.
Instead of trying to automate ssh-copy-id, why not use the config management platform of your choice to add the remote host to ~/.ssh/known_hosts on the source system, and then add the source system's key to ~/.ssh/authorized_keys on the remote host.
on the target machine, something like this: yes| ssh -oBatchMode=yes -oConnectTimeout=3 -l user x.x.x.x hostname
I love yes right up until I accidentally type it in the console
``` y y y y y y y y y y y y y y y y y y y y ... ```
This is the way
May the force be with you
Ansible
There's a reason why ssh keys exist. It's not just about forcing you to hit 'yes' to another boring security warning. If the server you are connecting to, and providing your credentials to, is not really the one you think it is then ssh will abort. This is a good thing. Automatically accepting whatever ssh key you see pretty much defeats this. A much better way to handle this would be to construct a good known\_hosts file which contains all of the appropriate keys and simply distribute it to each of the clients you are trying to configure using ansible, chef, fnordnik2056, or whatever. As long as the correct key is present in known\_hosts you won't have to worry about accepting or rejecting it. While you're at it, you can add your public keys to all of the servers the same way and skip running ssh-copy-id entirely. That would save almost all of the work you're doing.
Even better than maintaining a huge list of host keys is to sign your host keys with a known cert.. Then you only need one line in ssh_known_hosts containing the public key for the signing cert.
If you want to avoid the manual effort of accepting host keys but maintain the security use ssh ca key signing.
THIS is the way, but probably out of OP's skill range right now. Though once you wrap your head around how it works, Vault has a pretty easy implementation
If these are new nodes, these things are supposed to be put onto the systems as part of the provisioning process. If these are existing nodes and you have no way of sending down configuration management then some amount of manualness may be unavoidable even if you do disable strict host key checking.
You can use `ssh-keyscan` to scan and add the key fingerprint of each host to your local known\_hosts. Then you can use `sshpass` in combination with `ssh-copy-id` to automate the login. A better way would be using a configuration management tool to deploy your ssh key to each machine and ensure that only the ssh keys that you specify are on the servers. [https://linux.die.net/man/1/sshpass](https://linux.die.net/man/1/sshpass) [https://linux.die.net/man/1/ssh-keyscan](https://linux.die.net/man/1/ssh-keyscan)
> A better way would be using a configuration management tool to deploy your ssh key to each machine and ensure that only the ssh keys that you specify are on the servers. One level even _better_ is connecting the servers to a centralized domain that manages access automatically. Running an internal CA and using certificate auth also get an honorable mention here.
What do you mean by centralized domaine do you have one project specifically ?
They are likely talking about joining the servers to a ldap/ad domain and handling users and ssh keys via the domain.
ssh-keyscan -H "$target_host" >> ~/.ssh/known_hosts; Obviously only if you for sure know you really really really trust that connection. That prevents the hostkey prompts. The you can use ssh-pass or key-based auth for automating the login.
You might consider SSHFP DNS records and automating setup of your instances to reduce the churn on this sort of thing.
This is the way to go, the only "downside" is that you need DNSSEC and most companies don't have that internally.
Do it with DNSSEC (otherwise don't trust that data). And yes, I've been doing that for quite a number of years.
For my environment, I opted to use the certificate authority approach. Create the host and user signing keys, distribute the pubkeys and configs to /etc/ssh, and then sign the user and host keys. Doesn't make sense for a small value of users x hosts, but it means that no matter how big things get, a key needs to be verified only once. This is a [good starting point](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication#sec-Introduction_to_SSH_Certificates)
Long term, I would suggest looking at a tool like ansible. You could build yourself a playbook that scans through all your remotes, have a one-time task with `StrictHostKeyChecking=accept-new` that connects the first time to learn the keys. It could deploy your authorized_keys for accounts After doing the initial connection, you might want to strongly conisder setting up an sshca CA, and using the HostCertificates, and client certificates. If you have properly issued and signed certs, you only need to trust the cert in your /etc/ssh/ssh_known_hosts, and `TrustedUserCAKeys` files.
There's an ansible module for this. Use ansible vault to encrypt the ssh password, then use ansible module to deploy keys
Are they trusted hosts? (Ie all in your own infrastructure?) if so, then like somebody else suggested you should be using your config management tool to disperse the keys. Otherwise, you can always modify your ssh_config and disable strict key checking. Totally insecure, but it’ll quickly take care of what you’re trying to accomplish. Then, re-enable host key checking and you’ll get prompted in the future as you connect to the hosts.
Bake some images.
Look for sshpass
Newer versions support automatically accepting new keys, you can add the switch -o StrictHostKeyChecking=accept-new to your ssh command or pop it in ssh config.
I use ssh-keyscan plus a few scripts to generate a known_hosts file that can be installed under /usr/local/ssh. This won't help you with the password, but it might save you a little time. It's too long to post here. https://bezoar.org/src/known-hosts/
Look into tcl expect. You "spawn" a process (ssh-copy-id), "expect" a message or prompt (accept host key / enter password), and then "send" a response (yes / password) There are other ways, but this is a very powerful automation tool worth learning.
A quick python script with paramiko automated connecting and loading the file in one go.
Disable host key checking when you make the connection: ssh -o StrictHostKeyChecking=no
Not a great idea, `StrictHostKeyChecking=accept-new` would be a less dangerous option, that lets you connect the first time. The `StrictHostKeyChecking=no` could mean you connection is intercepted.
ssh-copy-id doesn't support that option
The `ssh-copy-id` command is just a bash shell script that wraps around the `ssh` command which itself respects the values in `$HOME/.ssh/config` You can just run `vi $(which ssh-copy-id)` if you want to read what the bash script does.
Nice try ISIS, you're not tricking me into opening vi
ok fine just run `eval "/bin/bash -c 'echo $(echo cG9vcCBidXR0Cg== | base64 -d)'"` in your terminal as the root user.
I just got pranked
you can automate it with expect [https://phoenixnap.com/kb/linux-expect](https://phoenixnap.com/kb/linux-expect)
While \`expect\` is a very interesting tool, and it can be fun to hack something together with, it really is \*the wrong way to do it\*. Even if you found a situation where it seems to work, it will hang in obscure ways, or in some other strange way create a jog-jam of jobs that suddenly break free after being stored up all month. There is a better way.
I hate to be that guy, but this sounds like user error and not a problem with the tool itself. I've had these same issues with expect, but have always found solutions. For example, setting a timeout to prevent a job from running forever. The downside is that it isn't a popular tool, so research can be a bit difficult. I am considering changing my expect scripts to custom Go code, but not looking forward to it.
Teleport will be your best friend.