Just FYI, nixops does not connect securely to several non-cloud-native backends like hetzner and physical machines, allowing potential hackers to intercept eg. deployment.keys sent to a machine.
Note that this has to do with StrictHostKeyChecking, which does not imply implies (see below) that host keys aren’t checked at all (eg. an attacker MITMing your already deployed host won’t succed). The main problem for the Hetzner target is that we can’t do a lot about it, because the rescue system (which is what is used for initial deployment) already comes with a newly generated host key every time and if you’re being MITMed during initial deployment, you’re already doomed at that point. That said, there is however a race in between the robot and the initial deployment, so if you’re rebooting from the rescue system into the newly deployed system the host key is added initially after the reboot. As mentioned in comments of that issue, this gap could be closed by generating the host key via nixops and sending it to the host during the first deployment.
Doing that however, still doesn’t solve the issue in the first place and we’d need a way to securely verify whether we’re in the real rescue system rather than a MITM host, so I’m going to ask Hetzner whether they could implement something like this (preferrably by getting the host key via Robot API).
Another attack vector is when you export the deployment without known_hosts and you get MITMed during the next connection after importing somewhere else.
So in summary: The situation (at least for the Hetzner backend) is not worse than it is even without NixOps (except maybe the export/import point mentioned before). If something like this is a concern to you, you probably shouldn’t use a hoster that regenerates SSH host keys in rescue, except of course if you have a way to verify that it’s indeed the real target system.
Nevertheless, that issue is on my todo list already, but it needs a lot of testing (and for the Hetzner backend a change of their API) so it might take a while
Edit: Actually, I was wrong on StrictHostKeyChecking… it really just adds the host key even on mismatch. While you do get big fat warning, this still will connect to the target anyway. OpenSSH 7.5 has the accept-new option, which I added in #1023. With this pull request merged, what I wrote above is the case (even with the goofs, this is not a full fix).
Edit 2: Hetzner does seem to have a way to get the host key of the rescue system: Robot Webservice
netcup runs on green energy, is available in english and in german, and allows you to upload your own iso file. I regularily build my own isos preloaded with my ssh keys etc.
It’s listed in the NixOS wiki’s NixOS friendly hosters page, together with more detailed installation instructions.
I use Hetzner too. They give you a choice of hydro power or wind power. And I like their control panel interface and backup options, and they’re very cheap.
