Can a malicious SSH server successfully *pretend* to know a client's public key?

Question

Yes, I know that after giving an SSH public key to someone else, one should always assume that it might have been swiftly published somewhere. (For instance, give your SSH public key to GitHub, and GitHub will publish it. E.g. presumably this one belongs to @Jeff Atwood, aka Coding Horror.) This question is about an exception to that general rule.

Suppose:

• SSH client C is attempting to log in to an SSH server S for the first time, as user u, via public-key authentication;
• C does not know S's SSH public key fingerprint (i.e. the host key fingerprint);
• S has a copy of C's public key in /home/u/.ssh/authorized_keys;
• nobody but C and S know C's public key;
• M is a malicious server identical to S in all respects (e.g. equally as capable as S is of presenting itself to C at the IP address where C expects to find S), except that M does not know C's public key.

Question: Can C distinguish between M and S?

Answer 1

In the simplest, one shot case, C would be able to distinguish between S and M by sending an invalid signature during the public key challenge. S would be able to compute that the signature is invalid because it has the correct public key.

Some public key signature schemes may provide an observer the public key if they can view multiple correct signatures created by the private key.

Answer 2

So if the client has no knowledge of the servers public key, and no authority to verify anything, then there is no way to distinguish between the authentic server and a malicious server. Because the malicious server would just generate a new private public key pair and provide the matching public key to the client and all the match would check out.

However the premise of the attack " equally as capable as S is of presenting itself to C at the IP address where C expects to find S" is unreasonable because every hope would need to be working together to incorrectly route to the wrong ipaddress so the malicious server could manipulate the packets without breaking the tunnel. Not impossible but definitely an edge case.

Answer 3

If you've never previously connected to the server and don't know the host key (or host fingerprint) of the server you are trying to connect to, a malicious ssh server could let a user in based on a public key authentication (or password authentication).

In fact, the malicious server can do a man-in-the-middle between the real ssh server and you, to authenticate with your connection in real time.

But this can be prevented by adding the true server's public host key to your /etc/ssh/known_hosts or the per user ~/.ssh/known_hosts file, and not blindly accepting unknown host certificates OR ignore errors when the host key doesn't match.