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?
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?
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:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
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.)
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.