The server is authenticated with a digital signature based on a DSA or RSA public-key algorithm. At the beginning of the connection, the server sends its public key to the client for validation.

Server authentication is done during Diffie-Hellman key exchange through a single public-key operation. When public-key authentication is used to authenticate the server, the first connection is very important. During the first connection the client will display a message similar to the one in Figure 6.2.

Figure 6.2. SSH Tectia Client on Windows – first connection to a remote host

To help you to verify the identity of the server host, the message displays a fingerprint of the host's public key. The fingerprint is represented using the SSH Babble format, and it consists of a pronounceable series of five lowercase letters separated by dashes.

At this point, you should verify the validity of the fingerprint, for example by contacting the administrator of the remote host computer (preferably by telephone) and asking the administrator to verify that the key fingerprint is correct. If the fingerprint is not verified, it is possible that the server you are connecting to is not the intended one (this is known as a man-in-the-middle attack).

After verifying the fingerprint, it is safe to continue connecting. A copy of the server public key will then be stored on the client machine. On SSH Tectia Client on Unix it is stored in the $HOME/.ssh2/hostkeys directory. On SSH Tectia Client and SSH Tectia Connector on Windows it is stored in the "%USERPROFILE%\Application Data\SSH\HostKeys" directory.

When the host key is received during the first connection to a remote host (or when the host key has changed) and you choose to save the key, its filename is stored in hashed format. The hashed host key format is a security feature to make address harvesting on the hosts difficult.

If you are adding the keys manually, the keys should be named with the key_<port>_<host>.pub pattern, where <port> is the port the Secure Shell server is running on and <host> is the hostname you use when connecting to the server (for example, key_22_alpha.example.com.pub).

If both the hashed and clear-text format keys exist, the hashed format takes precedence.

Note that the identification is different based on the host and port the client is connecting to. For example, the short hostname alpha is considered different from the fully qualified domain name alpha.example.com. Also a connection with an IP, for example 10.1.54.1, is considered a different host, as is a connection to the same host but different port, for example alpha.example.com#222.

After the first connection, the local copy of the server public key will be used in server authentication.