<p>You have to execute <code>ssh-keyscan</code>. For example to ssh to a host (github.com here ) you have to run below script </p>

<pre><code># Add ssh key to help cloning private github repo

ssh-keygen -t rsa -N "" -f secrets/ssh/github_rsa
PUB_KEY=$(cat secrets/ssh/github_rsa.pub)
PRV_KEY=$(cat secrets/ssh/github_rsa)

echo "${PRV_KEY}" &gt;&gt; ~/.ssh/github_rsa
chmod 600 ~/.ssh/github_rsa
eval $(ssh-agent)
ssh-add ~/.ssh/github_rsa

ssh-keyscan github.com &gt;&gt; ~/.ssh/known_hosts
echo IdentityFile ~/.ssh/github_rsa &gt;&gt; ~/.ssh/config

echo "Paste the following public key to your host machine ".${PUB_KEY}
</code></pre>

CC BY-SA 4.0
2018-11-11T06:10:34.243Z
Thanks, this works. A question, though. What (or rather, why) is being done in lines `eval...` thru `echo IdentityFile...` when it would seem that `ssh-keyscan github.com >> ~/.ssh/known_hosts` is sufficient?
LLlAMnYP
CC BY-SA 4.0
2018-11-11T07:43:36.587Z
The default ssh keys stored in id_rsa and id_rsa.pub. Note the name 'id_rsa'.  if you want to store those keys other than default name then you have to tell it to your ssh_agent. Though ssh-keyscan works in your case, I just gave a complete example incase you want to do the same from a CI server where you have to manually start ssh agent etc. However if that works don't forget to mark it as an answer. :)
SkyRar
CC BY-SA 4.0
2018-11-11T17:32:24.123Z
Well, since noone else chimed in, I guess, I can accept this one. Thanks again!
LLlAMnYP
CC BY-SA 4.0
2018-11-09T18:57:34.577Z
2018-11-11T07:36:18.637Z
2018-11-11T07:36:18.637Z
SkyRar
<p>This is a question that may be easier answered on askubuntu or, perhaps, serverfault, but it arises in the context of automated provisioning, so I figured that it's more appropriate here.</p>

<p>I am spinning up a multi-machine environment in vagrant, e.g. <code>n+1</code> ubuntu-18.04 boxes, namely</p>

<ul>
<li>term (short for terminal)</li>
<li>node1</li>
<li>...</li>
<li>nodeN</li>
</ul>

<p>They can all resolve each other by the above hostnames. It's necessary, that <code>term</code> can SSH into each of the nodes using its public key.</p>

<p>Manually I can do this with the following script:</p>

<pre><code>#!/bin/bash

head='node'

ssh-keygen -N '' -f ~/.ssh/id_rsa

for ((i=1; i&lt;=$1; i++)); do
  name=$head
  name+=$i
  ssh-copy-id $name
done
</code></pre>

<p>running, e.g., <code>./copyid.sh 3</code>. But then I have to type <code>yes</code> (to confirm the fingerprint of the node) and <code>vagrant</code> (the password) three times.</p>

<p>I want to move this procedure to the provisioning of the VMs in the Vagrantfile. So I have two questions:</p>

<ul>
<li>How can this be automated without demanding manual input from myself?</li>
<li>When I transfer over from virtual machines to bare metal servers, what best practices should I follow to prevent infosec guys from screaming "man in the middle" at me?</li>
</ul>

CC BY-SA 4.0
2018-11-09T14:53:02.273Z
This probably could help you: https://unix.stackexchange.com/questions/126908/get-ssh-server-key-fingerprint (running a keyscan on each host to add to your `term`'s known_hosts before doing the ssh-copy-id)
Tensibai
<vagrant><provisioning><key-management>
How do I automate population of known_hosts and authorized_keys?
LLlAMnYP
# How do I automate population of known_hosts and authorized_keys?

(Asked by: username_0 on 2018-11-09)

This is a question that may be easier answered on askubuntu or, perhaps, serverfault, but it arises in the context of automated provisioning, so I figured that it's more appropriate here.
I am spinning up a multi-machine environment in vagrant, e.g. n+1 ubuntu-18.04 boxes, namely

term (short for terminal)
node1
...
nodeN

They can all resolve each other by the above hostnames. It's necessary, that term can SSH into each of the nodes using its public key.
Manually I can do this with the following script:
#!/bin/bash

head='node'

ssh-keygen -N '' -f ~/.ssh/id_rsa

for ((i=1; i<=$1; i++)); do
  name=$head
  name+=$i
  ssh-copy-id $name
done

running, e.g., ./copyid.sh 3. But then I have to type yes (to confirm the fingerprint of the node) and vagrant (the password) three times.
I want to move this procedure to the provisioning of the VMs in the Vagrantfile. So I have two questions:

How can this be automated without demanding manual input from myself?
When I transfer over from virtual machines to bare metal servers, what best practices should I follow to prevent infosec guys from screaming "man in the middle" at me?

**Tags:** vagrant, provisioning, key-management

> **Comments:**
> **username_1**: This probably could help you: https://unix.stackexchange.com/questions/126908/get-ssh-server-key-fingerprint (running a keyscan on each host to add to your `term`'s known_hosts before doing the ssh-copy-id)  

---

## 1 answers

### Answer by username_2 on 2018-11-09. Score: 4 | Accepted answer

You have to execute ssh-keyscan. For example to ssh to a host (github.com here ) you have to run below script 
# Add ssh key to help cloning private github repo

ssh-keygen -t rsa -N "" -f secrets/ssh/github_rsa
PUB_KEY=$(cat secrets/ssh/github_rsa.pub)
PRV_KEY=$(cat secrets/ssh/github_rsa)

echo "${PRV_KEY}" >> ~/.ssh/github_rsa
chmod 600 ~/.ssh/github_rsa
eval $(ssh-agent)
ssh-add ~/.ssh/github_rsa

ssh-keyscan github.com >> ~/.ssh/known_hosts
echo IdentityFile ~/.ssh/github_rsa >> ~/.ssh/config

echo "Paste the following public key to your host machine ".${PUB_KEY}

> **Comments:**
> **username_0**: Thanks, this works. A question, though. What (or rather, why) is being done in lines `eval...` thru `echo IdentityFile...` when it would seem that `ssh-keyscan github.com >> ~/.ssh/known_hosts` is sufficient?  
> **username_2**: The default ssh keys stored in id_rsa and id_rsa.pub. Note the name 'id_rsa'.  if you want to store those keys other than default name then you have to tell it to your ssh_agent. Though ssh-keyscan works in your case, I just gave a complete example incase you want to do the same from a CI server where you have to manually start ssh agent etc. However if that works don't forget to mark it as an answer. :)  
> **username_0**: Well, since noone else chimed in, I guess, I can accept this one. Thanks again!  

---

