Handling a changed host key

After a host key has been accepted and saved, the user should not see this message again. However, if the host key presented by the server on a subsequent connection is different from the one saved on the user's local system, a second message will be displayed. Here is an example:

The host key sent by the server is different from the host key stored in the host key database for myserver (192.168.0.1), port 22. This may mean that a hostile party has "hijacked" your connection and you are not connected to the server you specified.

It is recommended you verify your host key before accepting.

Server's host key fingerprint (MD5 hash):

14:09:26:bc:13:24:31:5c:f7:6c:39:94:f7:4d:52:14

If you trust this host, enter "y" to add the key to the host key database and connect. If you do not trust this host, enter "n" to abandon the connection.

Accept and save? (y/n)

As you can see from the text of the message, a user seeing words such as "hijacked" might get very nervous. There are several scenarios that could cause this situation. The first is that the server has been compromised or you are experiencing a man-in-the-middle attack. However, this is not usually the case. Here are two more likely scenarios.

1. It's possible that the administrator changed the host key.
2. The machine the user is connecting to actually has more than one Secure Shell server running and the client is not keeping track of the different host keys for the different servers running on the same machine.

As with a new host key, before accepting the changed host key, the user should use a secure method to verify the host key being presented corresponds to the actual server. Here are a few methods to address this question of host authenticity.