- DH keys are used to achieve forward secrecy, they are unique for each session and ephemeral - there is no need and no way to pre-distribute them
- client authentication keys (RSA) already have the requirement to be pre-distributed - by placing the client public key in the user's
authorized_keys file on the server
- server authentication keys can be either pre-distributed by placing the server's public key in the user's
known_hosts file or accepted manually by the user on the first connection
Clarifications from the comments:
Looking for a way that a MITM cannot get a hold of the client public keys and spoof the server as a legitimate client.  the MITM could still try to send data to the server, as the server thinks he is the real client.
It could "try", but it wouldn't succeed. Public key is not a token which you present to the authenticating party to be matched. Public key is used by the authenticating side to decrypt the message sent and encrypted (signed) by the party being authenticated, thus ensuring it was encrypted with the corresponding private key.
Knowledge of a public key does not allow to impersonate the holder of the corresponding private key.
If someone "listening" acquires that clients public RSA key, won't they be able to use it to connect to the server? How would the server know if it is the actual clients RSA public key vs. someone else just using his public key?
Example: the server has three public keys configured for access
B sends a message encrypted with
privB. The server receives an encrypted message and tries to decrypt it using the public key
pubA--it gets gibberish. Then it tries to decrypt the message using
pubB and this time gets a valid message. It means the message was encrypted using
privB. The only entity that owns the
privB is B, thus the server confirmed B is the sender and grants the permission to access.
Someone encrypts the initial message with
pubB and sends it to the server. The server is not be able to decrypt it using
pubB (because it needs
privB, but only B owns the
privB, not the server).
pubB to the server, the server has no idea, what it is. It does not expect any key to be sent.
Above explanation is conceptual, the real key exchange algorithm is more complex as the content of the initial message must also be established