31–40 of 80 posts
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.
Earlier quoted context omitted.
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.
> Other comments say that this mitm stops working when you use public key authentication. It doesn't completely stop working; a MITM can still pretend to be the server, it just can't authenticate to the real server on your behalf. You could be doing all your work in a fake server controlled by the attacker, while the real server sits there untouched.
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? The client sends not only the public key, but also a signature, and that signature depends on the output from the key exchange, so it's "bound" to the shared keys negotiated between the client and the server. If the MITM server does separate key exchanges with the client (pretending to be the real server) and the server (pr…
MITM can take its public key and the client's public key and send the resulting signature to the server instead of forwarding what it received from the client.
Do pretty much the same exact thing: MITM PK + Server's PK -> Client. Now client has a signature as well. The signatures that client and server have are different but that is OK as long as MITM can see and change all communication.
It has been a while since I went through the details of the protocol, so I must be missing something. What is it?
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.
How do you compare? What trusted channel do you use to retrieve the real public key?
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.
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.
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.
Earlier quoted context omitted.
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.
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.)
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.
It baffles me why VPS providers don't display the fingerprints on their dashboards or expose them through the API.
A few do. Though a more common way of securing the loop is to take the desired user public key during the build process. Assuming you trust that the host control panel (or API server) hasn't been hacked, which you are assuming anyway if you trust a host fingerprint given to you that way, that should be as secure. For a small bit of extra assurance, to protect from an extra very unlikely attack, generate a new key pai…
but how real is this threat? you buy a box from hetzner or some VPS provider and its rooted when you try to ssh ?