If you don't assume the network between you and Hetzner is compromised, you might as well just use rsh instead of ssh.
replyThe box itself is probably fine. It's the path between you and it. In shared infrastructure one compromised hop somewhere upstream is enough and now you're SSHing into the wrong thing without realizing it.
replyYou get a box and someone is sitting on its IP address (in the middle), proxying to the real one, so everything is getting logged. Other comments say that this mitm stops working when you use public key authentication.
reply> Other comments say that this mitm stops working when you use public key authentication.
replyIt doesn't completely stop working; a MITM can still pretend to be the server, it just can't authenticate to the real server on your behalf. You could be doing all your work in a fake server controlled by the attacker, while the real server sits there untouched.
If that were the case then I don't think the OP approach works either.
replyIt does note that it only protects against an attacker "who learns the cloud-init user-data at any point after the script terminates".
replyIf the attacker can get the cloud-init user-data while the script is still running (in the time between sending the cloud-config.yaml and connecting with SSH to the machine) that would still allow MitM, but would require more effort on the attacker's part to leak the cloud-init data.
The point of the script was that leaking the cloud-init data after the script has completed is harmless.
Yes, I'm just saying if you think you've set up a server with Hetzner, but Smersh is able to intercept your first interaction with it and present you a server that you think is the one you created, then it doesn't matter how much you try to harden the compromised server. But if you get MITM later in the the process, the above is the scenario you are worried about.
reply