Information Security
public-key-infrastructure man-in-the-middle ssh spoofing sftp
Updated Fri, 20 May 2022 02:55:13 GMT

"Mutuality" of public key authentication


I'm a newbie when it comes to cryptographic security, but there's something I'm not quite getting concerning the "mutual" aspect of public key authentication.

Say you have a client X, and that client X needs to establish a secure SSH FTP connection to a server Y. To do so in a safe way, you create a keypair on your local machine using ssh-keygen, store the private key on the server making the request ("client"), and the public key V on the server Y, for the user Z.

You now connect via SSH FTP from the client X, by sending the public key V to the server Y, using the user Z. What I do not get is how this authentication is mutual? If for example an attacker gets access to the public key V, can't he spoof the server Y's IP with that public key V, and then intercept the traffic and retrieve all the unencrypted data from client X?

Or does public key authentication always also use the same process in reverse, meaning that the client first makes the request using the public key stored on the server, the server authenticates the signature, and then the client authenticates the answer from the server, with a signature which is computed with a private key on the server-side only?

As an example, I'm using phpseclib, but I don't see the mutual step in it. Is it actually on me to do the mutual step, e.g. by using this to verify the SSH fingerprint upon every connection ?

Basically, I'm just not getting how traffic using public key authentication is not vulnerable to traffic interecption if an attacker has access to the server's public key and spoofs / impersonates that server's IP.




Solution

Basically, I'm just not getting how traffic using public key authentication is not vulnerable to traffic interecption if an attacker has access to the server's public key and spoofs / impersonates that server's IP.

Because, in order to spoof the server, the attacker would also need the private key that corresponds with the public key.

See Could a stolen certificate show as trusted? for more info.





Comments (5)

  • +0 – Sry still don't get it; even after reading the linked post; as the private key is not transmitted to the server, only a digital signature which used the private key to generate it, correct? Isn't the same possible for a server "mimicking" the target server's ID by accepting SSH connections for the same user + the same public key? — Nov 05, 2021 at 10:46  
  • +0 – aaaah got it, you're actually saying that to spoof / impersonate the server, you need to establish a connection to the responding server first, and to do that, you obviously need the private key associated to the public key used for the authentication. Is that it? I just had in mind that an attacker may be able to impersonate the target server without any connection to that target server..? As I said, I'm a newbie.. — Nov 05, 2021 at 10:50  
  • +0 – What's actually confusing me in that sense is the following phrase of the phpseclib docs: "Public Key Authentication is one of the most secure ways to connect to a server. Even if the server is being "spoofed" or otherwise compromised the worst thing that'll happen is that the public key will be exposed to the attacker." This kind of contradicts what you're saying, or am I wrong..? Because, what's the interest in retrieving a public key if you've already spoofed the server, according to you meaning you have the associated private key?? — Nov 05, 2021 at 10:58  
  • +1'to spoof / impersonate the server, you need to establish a connection to the responding server first, and to do that, you obviously need the private key associated to the public key used for the authentication' is correct. — Nov 05, 2021 at 11:47  
  • +1 – WRT, "Public Key Authentication is one of the most secure ways to connect to a server. Even if the server is being "spoofed" or otherwise compromised the worst thing that'll happen is that the public key will be exposed to the attacker." - they are referring to the client here. If the server was compromised and the client attempts to connect. the client only divulges his public key (which is public anyway), so he didn't divulge anything sensitive (as would have been the case if he authenticated with a password). — Nov 05, 2021 at 11:49