Verifying Host Identity
When you connect to a remote host computer for the first time using public-key authentication, the host sends your local computer its public key in order to identify itself. This first connection is very important.
To help you to verify the host's identity, the Host Identification dialog displays a fingerprint of the host's public key. The fingerprint is represented using the SSH Babble format, and it consists of pronounceable series of five lowercase letters separated by dashes.
The fingerprint of the public key should be verified before you save it in the local database and proceed with the connection. If you do not verify the authenticity of the fingerprint, you risk the possibility of a man-in-the-middle attack. In future connections, the local copy of the server's public key will be used in server authentication.
If you have reason to suspect that the public key you have received may be forged, you can for example phone the system administrator of the remote host computer and check that the fingerprint is correct.
If your work requires the strictest degree of absolute security and you cannot trust the network that was used to deliver the host key, you can ask the system administrator of the remote host computer to deliver the host's public key to you personally, for example on a diskette. This way the key is never passed over the network and you can be absolutely sure that it has not been forged. When using the host key with an SSH Tectia Client connection, you can be sure that you are connecting to the correct host and that there is no possibility of outside intrusion. However, for ordinary use this procedure can be seen as overkill.
The Host Identification dialog asks if you want to store the host key on your local computer. If you connect regularly to the host you will probably want to keep the key. This prevents an attack where someone can steal your connection.
If you save the host key, you do not have to go through this procedure again the next time you log in. The host public key will still be checked with each connection, but this will be done automatically without user intervention.
The known host keys will be saved in a local database that is specific to each user of the local computer. This way each user will build a personal database of the public keys of known and trusted hosts.