0

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?

sampablokuper
  • 1,961
  • 1
  • 19
  • 33

3 Answers3

1

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.

noone392
  • 206
  • 1
  • 5
0

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.

dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • *"[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`"* I totally agree, but unfortunately that [isn't always possible](https://security.stackexchange.com/q/178504) :( – sampablokuper Jan 27 '18 at 01:58
-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.

John Downey
  • 1,915
  • 13
  • 12
  • why would the signature be invalid? The premise of this question is the first connect? – noone392 Jan 26 '18 at 23:57
  • This answer is not correct – noone392 Jan 27 '18 at 00:05
  • 1
    noone392, I think John Downey is saying that if **C**'s key is X, then **X** should pretend, for the first login attempt, that its key is some different, randomly-generated key Y. If the server rejects the connection then it is almost certainly **S**. Conversely, if the server accepts the connection then it is almost certainly **M**. – sampablokuper Jan 27 '18 at 01:54
  • @sampablokuper+ Altering the signature (only) doesn't work because the client publickey is sent in the USERAUTH message (see rfc4252) allowing M to check it just as well as S. However altering the key _and_ signature does distinguish M as you describe. – dave_thompson_085 Jan 27 '18 at 11:04
  • @dave_thompson_085, good point that I was perhaps over-generous in my interpretation of this answer. Thanks for corroborating the security properties of my interpretation of it, anyhow :) (Also, I just spotted a typo in my comment above: *s/then **X** should pretend/then **C** should pretend/*.) – sampablokuper Jan 27 '18 at 12:20