If a man in the middle relays a public key challenge, that will indeed result in a valid connection, but the connection will be encrypted such that only the endpoints (or those who possess a private key belonging to one of the endpoints) can read the resulting traffic. So the man in the middle is simply relaying an encrypted conversation and has no visibility into the decrypted contents.

The man in the middle can still perform denial of service, by dropping some or all of the traffic.

The man in the middle could substitute their own public key in place of one of the endpoint's public keys, but if each endpoint knows the other endpoint's key and is expecting that other key, then an unexpected substitute key will raise a red flag.

No, these schemes use the pub/private keys to setup symmetric crypto, so just passing it along does you no good because what follows is a bunch of stuff encrypted by a session key only the endpoints know.

If I am a server and have your public key in an authorized_keys file, I can just encrypt a random session key using that and only you will be able to decrypt it to finish setting up the session.

This is why passwords and asymmetric crypto are worlds apart in security guarantees.