on master help sign in
README: Explain that and why ob deploy init requires manual host verification
commit91c49dbcac4f97824ba40bd49c6e043f3d08a6cb authorElliot Cameron <eacameron@gmail.com> dateFri 6 Sep 2019, 22:05 (7 years ago) parentf02b2c3
1 file changed+4−2
README.md+4−2
README.md+4−2
@@ -167,9 +167,11 @@ ob deploy init \
167167 ~/code/myapp-deploy
168168```
169169
170−NOTE: HTTPS is enabled by default; to disable https, pass `--disable-https` to the `ob deploy init` command above.
170+HTTPS is enabled by default; to disable https, pass `--disable-https` to the `ob deploy init` command above.
171171
172−Then go to that created deployment configuration directory, and initiate the deployment:
172+This step will also require that you manually verify the authenticity of the host `$SERVER`. Obelisk will save the fingerprint in a deployment-specific configuration. **Obelisk deployments do *not* rely on the `known_hosts` of your local machine.** This is because, in the event that you need to switch from one deploy machine / bastion host to another, you want to be absolutely sure that you're still connecting to the machines you think you are, even if that deploy machine / bastion host has never connected to them before. Obelisk explicitly avoids a workflow that encourages people to accept host keys without checking them, since that could result in leaking production secrets to anyone who manages to MITM you, e.g. via DNS spoofing or cache poisoning. (Note that an active attack is a circumstance where you may need to quickly switch bastion hosts, e.g. because the attacker has taken one down or you have taken it down in case it was compromised. In this circumstance you might need to deploy to production to fix an exploit or rotate keys, etc.) When you run `ob deploy` later it will rely on the saved verification in this step.
173+
174+Next, go to the deployment directory that you just initialized and deploy!
173175
174176```
175177cd ~/code/myapp-deploy