Clearing a SSH Saved Host Key From the Exinda

Summary

When using SSH in any capacity (whether it's Secure Copy or attempting to SSH to or from the Exinda), it is required that the Exinda and the other client negotiate encryption based on Host Keys. Sometimes these host keys can change and might need to be modified in the Exinda

Overview

Secure Shell (SSH) is a way to remotely connect to a device as if was local. Part of the benefits of an SSH connection is that it secures the entire connection by the use of RSA. While this article will not do indepth into cryptosecurity or the underlying protocols on how cryptosecurity works, the following should be noted about how a connection is set up:

• A negotiation takes place between what is acting as the 'server' and what is acting as the 'client'.
• This negotiation chooses the security protocol that will be used to secure the connection
• The client and the server use common information to generate a session key to be used for the connection.

Before a session key can be established, the 'client' and 'server' need to be identified to each other. This is done through the use of 'RSA Fingerprints' - these are generated by every computer and are presented to another party when a connection is opened. Once a connection is established between a client and a server, the other party (the server and the client, respectively) can be marked as 'trusted' - that is, they will not ask for user intervention to accept the connection to the remote host. This is done by saying the 'RSA Fingerprint' of the other party to a local file. Then the hostname (or IP) is permanently associated with their RSA fingerprint.

If the RSA Fingerprint of a known host to the Exinda changes, it will throw up an error the next time a connection is attempted to that host.

Cause

While the RSA Fingerprint of a machine usually lasts forever, there are some cases where it can change. Notably, if a device is reformatted or reimaged, and is brought back online with the same name, the same IP and other same parameters. The RSA Fingerprint will be different, even though the name of the machine is the same.

For example, if there is a backup server that the Exinda routinely backs up to, and it was reimaged (or another device was brought in to replace it) and given the same identifiers (hostname, IP, etc), the next time the Exinda tries to connect to that known host (that has the same name but a different fingerprint), it will detect the mismatch and throw an error with some security information. If the device itself hasn't changed but the Exinda still detects a mismatch, it is possible there is a breach in the network and the connection is being hijacked.

Resolution

If the other party has been reimaged or replaced with the same name, the host can be removed from the list of known hosts in the Exinda. To do this, contact Exinda TAC for assistance.

When it is done, the next connection to the removed host will need to be reaccepted by an administrator so the new key can be added to the known hosts list.

Internal Notes

1. Input a restricted license
2. Go to the Shell (_shell)
3. Go to ~/ssh/ (cd ssh/)
4. Make sure the known_hosts file exists (ls)
5. Edit the known_hosts file (vi known_hosts)
6. Press 'i' to go into insert mode
7. Find the entry in the list that is either the hostname or IP of the machine they need to update
8. Delete that line. Be careful while doing it so that nothing else is erased.
9. Press 'Esc' then type ":wq" (without quotes). This will modify the file. IF THIS DOES NOT WORK AND SAYS INSUFFICIENT PRIVILEGES, YOU WILL NEED TO EXIT OUT OF VI (":q!" without quotes) and type 'remount rw')
10. SSH to the host by the way that they usually do (whether it was by host name or IP)
11. There will be a warning saying that there's never been a connection to this machine, give the RSA fingerprint, etc. There will be an option to connect and save this key. Do this.