1

If an attacker is able to gain access to the public key on a host server, they can setup a different machine between the client and the server, and place the key there.

When clients connect via SSH, they'll be presented with the same fingerprint as the original machine and their commands could then be intercepted by the attacker.

How does SSH avoid this?

Edit: this is in reference to passoword-less communication with the server

Daud
  • 189
  • 7
  • You might have mistyped public key for private key, otherwise your question does not make sense. A public key is publicly available by design and you can't use it on its own to impersonate the server. – Pedro Jun 03 '20 at 16:20
  • @Pedro When a client connects with a server, all the server has is the public key of the key pair that the client has generated. During the handshake, the server then confirms the identity of the client using a challenge question which only the client with the private key can answer. My question is that anybody can pretend to be the server because all that's required is the public key, which as you said, is freely available – Daud Jun 03 '20 at 16:42
  • ok so you're talking about authentication keys, not host keys. again having the public key yields nothing to the attacker. successfully impersonating the server involves using the server's private **host** key. – Pedro Jun 03 '20 at 17:39
  • just read this: https://en.wikipedia.org/wiki/Public-key_cryptography – Z.T. Jun 03 '20 at 21:02
  • @Pedro I was not aware of the involvement of host public and host private keys in the process, and that's why the confusion arose. Thanks for making the distinction clear. – Daud Jun 04 '20 at 08:33

2 Answers2

2

The attack would not succeed, because the Man In The Middle (MITM) needs to have not only the public key of the server, but also the private key as well, in order for the client to be able to complete the handshake with the MITM's server.

This question (and answer) are very similar to: Could a stolen certificate show as trusted?

Edit 6/4/2020: Once the ssh tunnel is setup, the client can authenticate with the server. One method of client authentication is 'public key authentication'. This is where the client proves that it is in possession of a private key that corresponds with a public key that the server has on file for the client. See comments below for more info.

mti2935
  • 19,868
  • 2
  • 45
  • 64
  • Since the true server also doesn't have the private key and is still able to complete the handshake with the client (which has the private key), the fake server should also be able to complete the handshake, no? – Daud Jun 03 '20 at 16:20
  • 2
    The true server presents a public key. The true server must also have the private key that corresponds with the server's public key, in order for the client to connect to the true server. See section 4 of https://tools.ietf.org/html/rfc5656, for how the key exchange process works. Without the private key, the server would not be able to sign the exchange hash. – mti2935 Jun 03 '20 at 16:53
  • 2
    I see that you edited your question to add, 'this is in reference to passoword-less communication with the server'. The client does not authenticate with the server (regardless of the authentication method used) until after the SSH tunnel is setup (see https://tools.ietf.org/html/rfc4252, section 11). This requires the server to have possession of the private key corresponding to the public key presented by the server, as I wrote above. – mti2935 Jun 03 '20 at 17:30
  • I was confused between authentication keys generated by the client (whose public counterpart is placed on the server) and the host public and private keys. In most articles on the net, I didn't find this difference stated clearly. Its much clearer now. If you feel the need, you can edit the answer after my source of confusion, and I'll mark it as accepted – Daud Jun 04 '20 at 08:32
  • 1
    Glad it's clearer now. DONE. Thanks. – mti2935 Jun 04 '20 at 10:21
2

How does SSH avoid this?

There's two key pairs at stake here. Host and Authentication keys.

  • If an attacker captures a private host key, they would be able to impersonate that server from the perspective of connecting clients. At this point you're left with one of two options:

    • a) Either create custom software to connect to the real server and monitor and tamper with communications
    • b) be an SSH server pretending to be the compromised server. In this case you'd also need to clone local user information and clients' public keys (usually under relevant authorized_keys files) otherwise clients will not be able to login to the "fake" server;

  • If an attacker captures a client's private key - and it is not encrypted - they would be able to impersonate the client, i.e. login on their behalf;

  • If an attacker captures a host public key... there isn't much you can do with it, as it is meant to be public;

  • If an attacker captures a client's public key... they can allow the client to login to a host of their choice...

Pedro
  • 3,911
  • 11
  • 25