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

JJoachimSchipper 2 days ago 16 commentsRead Article on joachimschipper.nl

ZH version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

50% Positive

Analyzed from 688 words in the discussion.

Discussion (16 Comments)Read Original on HackerNews

londons_explore•about 2 hours ago

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??

hnlmorg•about 2 hours ago

Couldn’t the MITM ssh server just forward the client’s fingerprint to the legitimate server?

If so, the legitimate server wouldn’t have anything in their logs that would help detect such an attack.

OpenSSH does log other telemetry though.

flumpcakes•about 1 hour ago

> Couldn’t the MITM ssh server just forward the client’s fingerprint to the legitimate server?

Fingerprints are derived from the certificates/private keys. Unless I don't understand some basic crypto, or SSH works in some obtuse way, I do not think it would be possible for the MITM attacker to present the server with the true client's fingerprint unless they also had had the client's private key.

hnlmorg•43 minutes ago

Ah thanks for the explanation. It’s been a long long time since I’ve delved this deeply into the topic.

INTPenis•about 2 hours ago

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.

flumpcakes•about 1 hour ago

This is something I have struggled with:

How to deploy secrets during bootstrap to a new virtual machine running in the Cloud that does not leave a trace in the infrastructure. And in a way that I can completely automate the deployment.

One answer is providing the secrets in cloudinit - but this leaves a trail on the host/provider's infrastructure, I do not know if those configs I paste into the portal then get saved off somewhere.

The other option (more secure) is having the keys/secrets generated on the host itself at first boot. But then this is difficult to automate as I would need to scrap them (even just the public parts) in a secure way. One option would be to have the public keys printed to the terminal/VNC - but this is much more trouble than it is worth to automate.

I'm not sure on a good solution. This is taking quite an adversarial security model though, assuming the host/provider is not completely trustworthy. Of course not owning the hardware means that the host/provider could be performing other attacks without my knowledge (copying memory, etc.)

unsnap_biceps•about 1 hour ago

I've been meaning to investigate Nitro Enclaves[1] for exactly this but haven't made the time yet. Have you looked into them and found them lacking?

[1] https://aws.amazon.com/ec2/nitro/nitro-enclaves/

IgorPartola•about 1 hour ago

1. Use cloudinit but give it a one time password to download the secrets on first boot.

2. Use certificates and your own CA.

3. Use the virtual serial console for first login.

4. Use cloudinit to add a custom software repo, then use that to install a custom package that does the initial work.

asalahli•about 1 hour ago

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

IgorPartola•about 1 hour ago

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.

crypt0r84•about 2 hours ago

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.

PunchyHamster•about 1 hour ago

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

lvlabguy•40 minutes ago

MitM is not possible if one uses public key authentication.

gruez•27 minutes ago

I was about to downvote this for being obviously false, but after some research this does appear to be true, because ssh uses some channel binding mechanism to prevent your public key authentication from being replayed/reused by the "man" in the middle.

zuzululu•about 1 hour ago

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

skydhash•about 2 hours ago

> 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.