Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

joachimschipper.nl

Post reply on HN
Print view View original

71–80 of 80 posts

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

#71

Post by cromka »

Borealid wrote: post #49
theteapot wrote: post #34

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

SSH has *ANOTHER* built-in solution, in the form of the SSHFP DNS record. If the DNS record for the host has an SSHFP (SSH FingerPrint) record, SSH will compare it to the retrieved public key(s) and refuse the connection if there is a mismatch. It can be configured to require DNSSec for this, or to only reject if it gets a secure rejection (to prevent DoS). It works perfectly, has no notable down sides (just add a DN…

Is there something like this for Wireguard?

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

#72

Post by egberts1 »

beagle3 wrote: post #60
Borealid wrote: post #49

Earlier quoted context omitted.

SSH has *ANOTHER* built-in solution, in the form of the SSHFP DNS record. If the DNS record for the host has an SSHFP (SSH FingerPrint) record, SSH will compare it to the retrieved public key(s) and refuse the connection if there is a mismatch. It can be configured to require DNSSec for this, or to only reject if it gets a secure rejection (to prevent DoS). It works perfectly, has no notable down sides (just add a DN…

It is very insecure unless you use dnssec, isn’t it? Just means an attacker also needs to mitm DNS if you MITM the host. Not trivial, but depending on setup might not be harder.

Correct. Very insecure unless your client app goes out of its way to perform DnSSEC.

But wait, there's more: SSH config, resolv.conf, DNS RR setup.

A lomg checklist for successful SSHFP deployment:

https://egbert.net/blog/articles/dns-rr-sshfp.html

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

#73

Post by Arrowmaster »

dboreham wrote: post #48
skydhash wrote: post #3

> 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 hav…

Attacker might have MITMed the console.

If they MITMed the console then they have probably MITMed the entire deployment process and now have the one time use key already.

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

#74

Post by debugnik »

gruez wrote: post #21
ekr____ wrote: post #20

Earlier quoted context omitted.

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 classi…

>* If you use SSH to copy a secret such as an API key to the server, then the attacker still knows the API key. That's much harder to pull off though, because you need to replicate the environment close enough so that the victim doesn't suspect anything. Do they put their config files in /var/lib or random docker volumes? Do they use docker compose or docker-compose, etc.

If you know its their first connection to a fresh VPS and assume they haven't used a web-based display to set up anything yet, you just need to guess their install image, which is probably off-the-shelf.

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

#75

Post by MaxBarraclough »

flumpcakes wrote: post #7
hnlmorg wrote: post #4

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

> Fingerprints are derived from the certificates/private keys

SSH fingerprints are derived from the public key. https://superuser.com/a/453022

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

#76

Post by Borealid »

egberts1 wrote: post #72
beagle3 wrote: post #60

Earlier quoted context omitted.

It is very insecure unless you use dnssec, isn’t it? Just means an attacker also needs to mitm DNS if you MITM the host. Not trivial, but depending on setup might not be harder.

Correct. Very insecure unless your client app goes out of its way to perform DnSSEC. But wait, there's more: SSH config, resolv.conf, DNS RR setup. A lomg checklist for successful SSHFP deployment: https://egbert.net/blog/articles/dns-rr-sshfp.html

That site doesn't mention that when DNSSec is absent, the behaviour of SSH is identical to what happens if you hadn't used the SSHFP record at all, except that for unsophisticated attackers it also displays "no matching host key found in DNS".

So even without DNSSec using the SSHFP records is an improvement over not using them because some of the time it tells you for certain you're being interfered with.

There is no situation in which an insecure DNS response is auto-trusted by the SSH client.

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

#77

Post by Borealid »

cromka wrote: post #71
Borealid wrote: post #49

Earlier quoted context omitted.

SSH has *ANOTHER* built-in solution, in the form of the SSHFP DNS record. If the DNS record for the host has an SSHFP (SSH FingerPrint) record, SSH will compare it to the retrieved public key(s) and refuse the connection if there is a mismatch. It can be configured to require DNSSec for this, or to only reject if it gets a secure rejection (to prevent DoS). It works perfectly, has no notable down sides (just add a DN…

Is there something like this for Wireguard?

Wireguard has no key distribution mechanism.

You can use software like Headscale/Tailscale/Netbird on top.

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

#78

Post by ranger_danger »

heinrich5991 wrote: post #65
londons_explore wrote: post #2

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…

Example of a nation state attacker that risked discovery and got discovered: https://notes.valdikss.org.ru/jabber.ru-mitm/ .

How do you know this was a nation state attacker?

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

#79

Post by zuzululu »

tptacek wrote: post #44
zuzululu wrote: post #11

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

If you don't assume the network between you and Hetzner is compromised, you might as well just use rsh instead of ssh.

Hope your home internet isnt compromised if it is thats a whole other problem

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

#80

Post by londons_explore »

ranger_danger wrote: post #78
heinrich5991 wrote: post #65

Earlier quoted context omitted.

Example of a nation state attacker that risked discovery and got discovered: https://notes.valdikss.org.ru/jabber.ru-mitm/ .

How do you know this was a nation state attacker?

Linodes response of 'we have observed no illegal activity and are closing this ticket' is as close as you can get to 'yes, this is a legal wiretap and we aren't allowed to tell you about it'.
Post reply on HN