but how real is this threat? you buy a box from hetzner or some VPS provider and its rooted when you try to ssh ?
Stop MitM on the first SSH connection, on any VPS or cloud provider
11–20 of 80 posts
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#12The 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.
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…
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?
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#13Seems 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
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#14There 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.
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#15Earlier quoted context omitted.
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.
> 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.
Ah thanks for the explanation. It’s been a long long time since I’ve delved this deeply into the topic.
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#16MitM is not possible if one uses public key authentication.
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#17MitM is not possible if one uses public key authentication.
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.
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#18A 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…
[dead]
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#19but how real is this threat? you buy a box from hetzner or some VPS provider and its rooted when you try to ssh ?
You 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.
Re: Stop MitM on the first SSH connection, on any VPS or cloud provider
#20MitM is not possible if one uses public key authentication.
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.
This is one of those situations where it's necessary to be very precise about the security properties.
Specifically, if you bind authentication to the connection, then an attacker who impersonates the server (in this case because it's the first connection, but in other settings because they have a fake certificate), then client authentication is not portable to another connection, so the attacker can't mount a classic MITM attack. However -- and this is a big however -- that doesn't mean that there aren't serious security problems. For example:
* If you use SSH to copy a secret such as an API key to the server, then the attacker still knows the API key.
* If you download some file (e.g., a script) from the server and then trust it, the attacker can use that to provide a malicious script.