Tectia

Authenticating Remote Server Hosts

Fetching Remote Server Keys

Remote Secure Shell servers are authenticated by a public-key procedure. The client trusts the server if it has a private key that matches one of the public keys in the global hostkeys directory or in the user's hostkeys directory. When a server presents a key that is not in the hostkeys directories, the user checks the fingerprint of the remote server's public key. When the user has approved the public key, it is stored in the user's $HOME/.ssh2/hostkeys directory and will be used automatically thereafter.

The verification step normally requires user interaction, so even for users that are set up to run client programs unattended, the first connection must be done by a person who logs in as the user, accesses the remote server, and goes through the fingerprint check dialog. The same steps must be repeated if the remote host's key is changed.

[Caution]Caution

When ssh-keydist-g3 is run with the -N option, it accepts the received host keys automatically without prompting the user. You should verify the validity of keys after receiving them or you risk being subject to a man-in-the-middle attack.

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 by default stored in hashed format, keys_hhh..., where hhh is a hash of the host port and name. The saved file contains a hash of the host's public key. The hashed host key format is a security feature to make address harvesting on the hosts difficult.

In the plain (traditional) format, the name of a host key file includes the hosts's name and port, as in key_22_host.example.com.pub, and the file contains the host's public key in plaintext format.

The key storage format can be set in the ssh-broker- config.xml configuration file, or on the ssh-keydist- g3 command line with the -F option. The command- line option takes precedence over the setting in the configuration file.