Inject a temporary SSH host key via cloud-init, use it only to retrieve the real long-term host keys, leaving no private key material exposed in userdata.
Key Takeaways
The technique works on any provider supporting cloud-init, including Hetzner Cloud, which has no proprietary first-connection verification solution.
Injecting a long-term private key directly via cloud-init is insecure: any process on the VM can read it from the metadata service at http://169.254.169.254.
The temporary key is never written to ~/.ssh/known_hosts; the script relies on OpenSSH key rotation to place only long-term keys there.
Leaks of cloud-init userdata after script termination are harmless because the temporary key is no longer valid.
The threat model explicitly excludes attackers who have already connected to the VM; logging is cited as the practical enforcement mechanism.
Hacker News Comment Review
Commenters pointed out two existing provider-independent alternatives: SSH certificate authorities (signing host keys with a CA) and SSHFP DNS records, both of which solve the bootstrap problem without this script.
Debate over whether MitM is realistic at all was common, but the actual risk is password reuse or agent forwarding on the first connection to an attacker-controlled proxy, not key exchange compromise.
Several commenters noted that a handful of VPS providers already expose host fingerprints via dashboard or API, making this unnecessary where supported.
Notable Comments
@tptacek: “If you don’t assume the network between you and Hetzner is compromised, you might as well just use rsh instead of ssh.”
@Borealid: SSHFP DNS records with DNSSEC offer a zero-script alternative that SSH already supports natively.
