From issue #696:

  The hardcoded -o StrictHostKeyChecking=no everywhere is a big SecOps
  no-no. It's quite feasible an attacker could wind up with an IP
  address you neglect to change after relinquishing, and have an entire
  host config hand-delivered to him to inspect for vulnerabilities. He
  wouldn't be able to MITM the the deployment, but obtaining what is
  essentially a dump of the host's whole filesystem is still pretty
  disastrous, from a defensive standpoint.

I by myself have been guilty of using this (added this to the Hetzner
backend), because I did actually misunderstand the meaning of setting
this option to no. My understanding was that it will refuse to connect
whenever an existing host key is different from that in known hosts.

However, this turns out to be only true for keyboard interactive or
password authentication and if we're using pubkey auth, OpenSSH will
happily connect.

Now the real fix for this (already deploying with a pre-generated host
key) is a bit more involved, but we can mitigate this for now, because
since OpenSSH 7.5 there is the "accept-new" option to
StrictHostKeyChecking, which does exactly what I thought "no" would do:

  If this flag is set to ``accept-new'' then ssh will automatically add
  new host keys to the user known hosts files, but will not permit
  connections to hosts with changed host keys.

Signed-off-by: aszlig <aszlig@nix.build>

Partially mitigate StrictHostKeyChecking=no issue