Stop MitM on the first SSH connection, on any VPS or cloud provider

> The technique appears to be new: I haven't found a proper write-up of this, nor of any other provider-independent solution.

Maybe I'm missing something but SSH already has a built-in solution for this, key-certs. Just sign the server key with a private CA key you trust.

I'm supposed to believe MitM with the same exact keypair is somehow possible? Private keys are never exchanged. Did everybody forget how crypto works?

Yes you implicitly trust the public key on first login.... then just... immediately compare it with what's on your box?

Might as well seal your doors with duct tape to prevent ghosts from entering your home because this is equally effective.

A big class of attacker is nation state attackers who do not want to risk discovery.

A big way to deter them is to keep remote log files which, if analyzed, will reveal any attack.

For example, if both ssh-client and ssh-server kept a fingerprint of the session key in some append-only logfile, then a later administrator could compare the logfiles to know if an MITM happened.

Suddenly, nation state attackers won't be interested in MITM-ing at all.

Unfortunately it appears openssh doesn't even have an option to create such a logfile!! Why not??

The author essentially bootstraps their servers with a known trusted host key, so that first connection is recognized, instead of having to trust a new and recently generated host key when you first connect.

It's a neat little trick if you're often deploying VPS in shared cloud environments.

It baffles me why VPS providers don't display the fingerprints on their dashboards or expose them through the API.

So this is a tangent on a thought i had after reading the title, but it might be a cool idea that I'll not have the time to do anything with so feel free to use it:

Human checkable fingerprints for pubkeys/hashes dont really work. None of the schemes i've seen hold up under somebody willing to spend compute to get a near-enough collision to fool most people most of the time.

But we can take those random bits and transform them and feed them into a seeded image generation LLM, and then have a person remember/compare the deterministic output image.

You might even make the case its the perfect machine to create memorable-2-human image artifact from random data.

MitM is not possible if one uses public key authentication.

provision the hosts with an SSH CA, use the CA as a trust root in openssh. they are various version out there from the big players.

There was ages ago a project called monkeysphere that let you sign the host ssh key with your gpg key and verify it automatically. The downside was that it was very slow.

but how real is this threat? you buy a box from hetzner or some VPS provider and its rooted when you try to ssh ?

zero touch prod might be something folks should keep as a north star - SSH should be break glass and a last resort if possible.

https://www.usenix.org/conference/srecon19emea/presentation/...

> The technique appears to be new: I haven't found a proper write-up of this, nor of any other provider-independent solution (but I'd welcome a correction).

To be frank, anyone that serious about security would probably log in via console, generate and retrieve the host key that way. And then any client would have strict verification enabled.

It's kinda the 101 of communication using public keys cryptography. You have to get hold of the public key in a secure manner first (direct contact or attestation by a third party).

Section 3.1 in Bruce Scheiner's Applied Cryptography discuss how to automatically solves MITM. But that's only important for M:N communications (TSL). For 1:1 communications where you can have secure exchange before hand, no need to go that far.

Seems like way easier way would be sshing for the first time and just typing `sudo reboot`. If VM reboots, it is yours

Or cat-ing some secrets that would be on target machine but not attacker