SSH: Duplicate SSH Host Keys

Overview

On Monday, October 10th, 2005, ECN will be updating UNIX hosts that have Secure Shell host keys that are duplicates of other Secure Shell host keys. After the changes are complete, it might be possible that Secure Shell will start complaining about invalid host keys when it did not complain before.

This document will describe what Secure Shell (ssh) host keys do and how to fix connection problems should the database update break a previously operating connection.

How SSH Works

Ssh is a safer alternative to the telnet command. It allows for terminal communication to a remote host, but encrypts the communication stream so that someone snooping for network packets between the two hosts cannot read the communication data, including sensitive information such as passwords.

In order for ssh to work effectively, each host creates a host key. The host key should be unique for each host and should be used to verify that the host you are attempting to connect to is truly the host you are connecting to. Without verifying the host's key, you might be subjected to a "man in the middle" attack.

Verifying that the connection to the remote host makes it to the correct host is as important as keeping your password secret. If another host can replace the correct host, then it could also be stealing your password.

Fortunately, ssh automatically verifies that the host is authentic by comparing the host key in a local database against what the host sends when you connect.

There are two places where the host key is kept. There is a master host key database and a personal host key database. The master host key database is created by ECN with all of the ECN hosts already populated and is satisfactory for most situations. The personal database stores additional host keys when you communicate with a host not supported or outside of the ECN network.

Details

ECN maintains a master list of host keys for all ECN support UNIX hosts. This master list is used in order to assist users with connections without having to verify the identity of remote hosts when connecting with ssh.

The master database file is located in either /var/ssh/ssh_known_hosts or /etc/ssh/ssh_known_hosts depending on where the operating system places the master file.

When we change some of the host keys on October 10th, we will also update the master ECN host key database with the new key information.

The Problem

The problem with changing a host key arises when the personal database of ssh host keys has an old key and conflicts with the new host key. For example, here I attempt to connect to Shay, and I have inadvertently stored a different host key for Shay:

min$ slogin shay
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
7d:2d:6a:a0:70:28:28:f2:98:1d:53:96:e2:ff:5a:28.
Please contact your system administrator.
Add correct host key in /home/shay/a/bliga/.ssh/known_hosts to get rid of this message.
Offending key in /home/shay/a/bliga/.ssh/known_hosts:3
RSA host key for shay.ecn.purdue.edu has changed and you have requested strict checking.
Host key verification failed.
min$ 

In this case, the host key for Shay is in ssh's personal host key file and is conflicting with the one presented by the host.

When this conflict arises, check to see if the host key really has changed (there is a list farther down this page).

To clear the error, delete the old host key and attempt to reconnect to the host. Without the host key in your personal database, ssh may begin by prompting you to confirm that the new host key needs storing. Type yes to confirm the new key and you're done.

Deleting the ssh host key from your personal database will depend on the ssh client. On the UNIX systems, the personal host key data is stored in your home directory in a file called .ssh/known_hosts. The file contains one line for each host and type of key. Delete all lines that match the name of the host and save the file.

On PC computers, the database is located in different spots depending on the client software. For example, using SecureCRT, go to the menu item Options -> Global Options..., then click on the option for SSH2 -> Host Keys. Click on the host name and click on Delete.

Key Changes

There are three types of changes that will occur on October 10th.

Complete Key Changes

In the following list of hosts, all of the Secure Shell host keys will changes. There are three types of keys available to each host: (1) the ssh version 1 key, (2) the ssh version 2 key using RSA authentication, and (3) the ssh version 2 key using DSA authentication.

SSH1 Key Changes

In the following list of hosts, only the ssh version 1 key will change. This change is probably the least bothersome as most all ssh communications is done using ssh version 2 protocol.

Removal From Database

Finally, in the following list of hosts, all keys will be removed from the master database. These hosts are a set no longer under ECN support.

Conclusion

If you have any questions or concerns, feel free to contact the ECN Software Support Staff at software@ecn.purdue.edu.