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

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

reply
Sure. I'm not saying it's not better to use public key authentication (it is!). Just that it's still possible to have problems.
reply
Basically, the client signs the shared key obtained through Diffie-Hellman key exchange, which then gets verified by the server. This ensures that the client and the server have the same shared key, hence no man-in-the-middle.
reply