[Contents] [Index]

About This Document >>     Installing SSH Tectia Server (M) >>     Using SSH Tectia Server (M) >>     Troubleshooting SSH Tectia Server (M) >>     Configuration >>     Authentication >>         Server Authentication with Public Keys >>             Server Configuration             Client Configuration         Server Authentication with Certificates >>         User Authentication with Passwords         User Authentication with Public Keys >>         User Authentication with Certificates >>         Host-Based User Authentication >>         User Authentication with Keyboard-Interactive >>         User Authentication with GSSAPI >>     Application Tunneling >>     Sample Files >>     Man Pages     Log Messages >>

Server Configuration

If you want to avoid the risk associated with the first connection, you can copy the server public key in advance to the /etc/ssh2/hostkeys directory on the client computer and set the StrictHostKeyChecking keyword in the ssh2_config file to yes. After this, ssh2 will refuse to connect if the server's public key is not in the /etc/ssh2/hostkeys directory.

The key pair used for server authentication is defined on the server in the sshd2_config file with the following parameters:

HostkeyFile <private hostkey> PublicHostKeyFile <public hostkey>

During the installation process, one DSA key pair (with the file names hostkey and hostkey.pub) is generated and stored in the /etc/ssh2/ directory. By default this key pair is used for server authentication.

In SSH Tectia Server, each server daemon can have multiple host keys. The daemon supports one DSA and one RSA key pair. You could have, for example, the following set of parameters in your sshd2_config file.

# RSA key HostkeyFile hostkey_rsa PublicHostKeyFile hostkey_rsa.pub # DSA key HostkeyFile hostkey_dsa PublicHostKeyFile hostkey_dsa.pub

Both keys are stored in memory when the sshd2 process is started, which means that either one of them can be used to authenticate the server.

By default, the server uses a public key with the filename of the private key plus the extension .pub. The PublicHostKeyFile keyword has to be defined only if the public-key file is stored with a different filename.

If also certificates are used in server authentication, SSH Tectia Server can have additional two host key pairs (DSA with certificate and RSA with certificate) for a total of four host keys.

Generating the Host Key

The host public-key pair (DSA) is generated during the installation of SSH Tectia Server. You only need to regenerate it if you want to change your host key pair, or if the host key was not generated during the installation.

To generate the host key, perform the following tasks:

1. Login as root.
2. Generate the host key with the following command:

   # ssh-keygen2 -P /etc/ssh2/hostkey
   

   Note: This will generate a 2048-bit DSA key pair (without a passphrase). For more information on the key generation options, see the ssh-keygen2 man page.
3. Restart the server as instructed in Section Starting the Server.

Notifying the Users of the Host Key Change

Administrators that have other users connecting to their server should notify the users of the host key change. If you do not, the users will receive a warning the next time they connect because the host key the users have saved on their disk for your server does not match the host key now being actually provided by your server. The users may not know how to respond to this error. SSH Tectia Manager (available separately) provides an automatic mechanism for distributing the host keys.

You can run the following to generate a fingerprint for your new public host key which you can provide to your users via some unalterable method (for example, by a digitally signed e-mail or by displaying the fingerprint on secured bulletin board):

# ssh-keygen2 -F hostkey.pub

When the users connect and receive the error message about the host key having changed, they can compare the fingerprint of the new key with the fingerprint you have provided in your e-mail, and ensure that they are connecting to the correct sshd2 daemon. Inform your users to notify you if the fingerprints do not match, or if they receive a message about a host key change and do not receive a corresponding message from you notifying them of the change.

This procedure can help ensure that you do not become a victim of a man-in-the-middle attack, as your users will notify you if the host key fingerprints do not match. You will also be aware if the users encounter host key change messages when you have not regenerated your host key pair.

It is also possible to send the public host key to the users via an unalterable method, for example, by using SSH Tectia Manager. The users can save the key in the ~/.ssh2/hostkeys directory as key_22_<machinename>.pub (automatic with SSH Tectia Manager). In this case, manual fingerprint check is not needed and the StrictHostKeyChecking option can be enabled on the client.