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

51–60 of 80 posts

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

#51

Post by minitech »

washingupliquid wrote: post #35
leni536 wrote: post #31

Earlier quoted context omitted.

How do you compare? What trusted channel do you use to retrieve the real public key?

Public keys go over untrusted channels. That's why they're public . I'm not confident you understand how crypto works. You do realize the entire threat model here is a house of cards perched atop someone else's software hosted on someone else's hardware all of which you implicitly trust and discard in favor of some unlikely cloak and dagger interception scheme.

> in favor of some unlikely cloak and dagger interception scheme

someone who definitely understands how crypto works, describing the most basic possible MITM

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

#52

Post by jmholla »

TacticalCoder wrote: post #37

> inject a temporary SSH host (private) key via cloud-init... Reading the comments here I'm tempted to believe that if cloud-init is available and if we consider Heztner (and OVH etc.) provides a secure access to cloud-init (i.e. the box running cloud-init is really the box you think it is), then there are many different ways to solve this problem.

I've been thinking of setting up a simple server that publishes the public keys at a known endpoints. You point an A record for one of your subdomains at the machine and it can provision a TLS cert. Then you can be reasonably confident your connection hasn't been MitM (assuming your trust your cert provider) when you query for those public keys.

The one presented in the article has fewer moving parts though. I'm also curious what ideas are bouncing around your head if you're willing to share.

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

#53

Post by kayson »

denkmoon wrote: post #46
kayson wrote: post #42

I've been fighting against this chicken and egg problem in my homelab. I have a step CA SSH CA set up along with automated deployment, bootstrapping, and cert renewals with an ansible playbook. It sets StrictHostKeyChecking yes in the ssh_config for my domain so I'm happily protected against a very unlikely attacker that has a foothold in my network. Theoretically, it means I should never have to worry about host key…

Though the name is cloud-init, you can cloud-init physical hosts. Seems excessive though, how often are you adding new physical hosts to the homelab?

True. But it means you have to get it into the installer/image which just doesn't seem worth it for something that, as you point out, doesn't happen all that frequently.

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

#54

Post by akerl_ »

washingupliquid wrote: post #38
comex wrote: post #36

Earlier quoted context omitted.

Public keys can go over channels that an attacker can read. They cannot go over channels that an attacker can modify . (Which would include the SSH connection itself, until such time as you’ve verified the key through a trustworthy channel.)

A public key is useless without the private key. Which the attacker in this unlikely scenario doesn't have. So you login the first time and they either match, or they don't. If they don't you start over. The end. Ignore the fact that most people will probably use the box to host a poorly coded vulnerable service anyway.

If you’re being MITM’d, they’ll also match, because you’ll end up connected to an environment of the attacker’s choosing.

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

#55

Post by wiml »

athrowaway3z wrote: post #25

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

There are a bunch of methods for transforming a hash into something that's easier to compare. You've probably already seen the RandomArt thing that openssh uses for comparing host keys on first use. Some apps produce a sequence of emoji for fingerprint comparison. It's a small but fertile little research niche.

I can't offhand think of anything that an LLM image generator would do to improve the process; it'd be an interesting research task. You'd need a way to transform the 256-bit hash into LLM input in a way that would maximize the perceptual difference in generated images. The problem is that it's absolutely critical that two different implementations work the same, which means the spec would need to specify the exact set of model weights to use.

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

#56

Post by Groxx »

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.

To try to add some explanation here: the server doesn't send the fingerprint. The server sends the public key, your computer just shows a fingerprint because it's more human-friendly and sufficiently secure.

If they forward the real key, so it matches the fingerprint, and you use it, they can't MITM the request because they can't read the contents.

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

#57

Post by bitfilped »

iberator wrote: post #41
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…

how would you create REAL write only logs? syslog > /dev/lpt0 printer?

Forwarding to WORM tape is one way. Of course that still involves network and likely a buffer somewhere.

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

#58

Post by SoftTalker »

So you inject a host ssh key pair at VM creation using cloud-init, then connect one time trusting that key and immediately replace the host keys in the VM. So there is still a brief race condition where the attacker could impersonate the VM if he had intercepted your cloud-init file, correct?

Also I don't see anywhere that the script reloads the sshd daemon, which AFAIK is necessary to get it to start using the new host keys and stop using the deleted initial host key.

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

#60

Post by beagle3 »

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…

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.

Post reply on HN