I've a ssh host key login setup in a remote server, for some reason, the DNS of that host is mapped to another server.

So assume the mistaken host cannot be trusted, should I change my key?

2 Answers 2


When you connect to the wrong server, this should trigger a very noticeable client-side warning, because the server appears to use a key distinct from the key it was using in previous sessions. The client remembers servers' keys. For a classic OpenSSH client, the warning looks like this:

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.

Of course, this relies on your client having already connected at least once to the right server; otherwise, the client will not know the right server key in advance.

Assuming that you did "click through" the warning (i.e. modified your .ssh/known_hosts to bypass it), then you connected to the wrong server. When using key-based authentication, the client computes a digital signature on a string which contains the "key exchange hash", a session-specific value obtained from the key exchange mechanism through a hash function; the server verifies the signature with regards to the expected client's public key (in .ssh/authorized_keys).

In no way is the client's private key ever revealed to the server. Moreover, inclusion of the key exchange hash in that which is signed prevents the receiving server (the wrong/fake one) from reusing the signature to impersonate the user on the right server. Therefore, your client private key is safe; there is no need to change it.

(The key-based client authentication mechanism is described in section 7 of RFC 4252.)

  • Thanks for the great explanation. I did exactly what you said, connected the wrong server and accepted the warning with a second mistake. So in short, you say I am still safe and my private key is not shared at all?
    – Tarik
    Commented Mar 22, 2018 at 17:28

If you are worried that you leaked your private key, at no point your private key is sent to the other server. As Thomas explains in his answer How does ssh public key authentication work?:

The core concept remains the same: the client proves its control of the private key by performing an operation which requires knowledge of that key, but such that the "inverse" operation can be done with the public key which is located in the .ssh/authorized_keys on the server.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .