Setting up the Server Public Keys

 » Table of Contents

 » Glossary

 » Index

Any connection request from a client to an SSH server requires that the client obtain the server's public key.

During SSH server configuration, the TCPIP$CONFIG configuration procedure creates the systemwide directory TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2.HOSTKEYS]. On a connection request, the SSH client checks this directory for the appropriate server's host key and proceeds with authentication if the key is found.

You can copy into this directory the host keys of all the remote servers to which you will connect from the client host. You can specify the public key file to copy from the client when you make the first connection to the server, or you can copy the public key files manually.

Automatically Copying Key Files

On a connection request, the SSH client checks the user's [username.SSH2.HOSTKEYS] directory for the appropriate server's host key and proceeds with authentication if the key is found. If the file is not found in either the systemwide or account-specific [username.SSH2.HOSTKEYS] directory, the first time that the user makes a connection from the SSH client to a remote SSH server, the user is prompted to accept a copy of the server's public host key (by default). This behavior can be controlled using the StrictHostKeyChecking parameter in the client configuration file. This parameter accepts the following values:

  • yes -- Causes authentication to fail if the file is not found.

  • no -- Causes the SSH client to create the [username.SSH2.HOSTKEYS] subdirectory (if it does not exist), and copies the SSH server's public key file into this subdirectory automatically.

  • ask -- Causes the SSH server to prompt the user for a copy of the server's public host key. This is the default.

If the StrictHostKeyChecking parameter is set to ask, and if the server's host key is in neither the server nor the client's HOSTKEYS directory, the following message is displayed:

Host key not found from database.
Key fingerprint:
xikan-rokyr-miduc-zofut-nysig-ciryt-pyroc-fegil-zadyb-cokel-loxex
You can get a public key's fingerprint by running
$ ssh_keygen "-F" publickey.pub on the keyfile.
Are you sure you want to continue connecting (yes/no)?

If you respond yes, the SSH client automatically creates the subdirectory SYS$LOGIN:[username.SSH2.HOSTKEYS] (if it does not exist) and copies the server's public key into this directory.

If you do not specify the StrictHostKeyChecking option, the default is ask.

SSH uses the [.SSH2] subdirectory to store multiple files needed for SSH to function. This directory is created automatically by the SSH software, or the user can create one in the login directory (as defined by SYS$LOGIN). For example, if SYS$LOGIN is defined as DKA0:[username], then the SSH2 subdirectory is DKA0:[user-name.SSH2]. Throughout this manual, this directory is referred to as the [username.SSH2] directory.

If necessary, you can create an SSH2 subdirectory in your user directory by entering the following commands:

$ SET DEFAULT SYS$LOGIN$
$ CREATE/DIR [.SSH2]

Manually Copying the Key Files

If your SSH client host does not have keys from remote servers in the systemwide directory, you can copy the keys manually, as follows:

  1. Create the subdirectory [.HOSTKEYS] in the user's SSH directory.

  2. Copy the server's public key to this directory using the COPY/FTP command. Specify the proper access privileges (for example: S:RWED,O:RWED,G:RE,W:R).

    The format for the file name is KEY_portnumber_hostname.PUB, where:

    • portnumber is the port number to be used to connect to the SSH server (22 by default).

    • hostname is the host name used to connect to the SSH server (either hostname or hostname.COM. Any dots in the host name are converted to underscore characters (myhost.com becomes myhost_com).

If necessary, the file format is converted to Stream_LF format and the following message is displayed:

$ ssh VMSHOST
warning: Converting file ssh2/hostkeys/key_22_vmshost.pub to Stream_LF.
warning: File ssh2/hostkeys/key_22_vmshost.pub converted successfully to Stream_LF.
Authentication successful.

If the public key file cannot be converted, the following error message is displayed:

Error calling CONV$PASS_FILES for ssh2/hostkeys/key_22_vmshost.pub. 
Status = {status text}

In this case, you can convert the file to Stream_LF format using the following command:

$ convert/fdl=SYS$SYSTEM:TCPIP$CONVERT.FDL keyfilename.PUB keyfilename.PUB

Where keyfilename is device:[username.SSH2.HOSTKEYS]KEY_22_remotename.PUB.

Naming Conventions for the Server's Public Host Key

By default, the server's public and host private key pair files are named HOSTKEY and HOSTKEY.PUB. When you copy these these files manually, you must rename them following the proper naming conventions. (When SSH copies the files, the proper file name is assigned automatically.) The name of the remote SSH server's public key on the client host must be in the following format:

KEY_port_hostname.PUB

The port is typically 22. The hostname is the name of the remote SSH server. For example, when you copy the public key from the remote SSH server MYSERVER to the client host, the key name becomes KEY_22_MYSERVER.PUB. If the remote server's name uses dot notation in its name (for example, MYSERVER.MYLAB.COM), SSH replaces the dots with underscores (for example, KEY_22_MYSERVER_MYLAB_COM.PUB).

For example, connect to an SSH server using the following command:

$ SSH USER@MYSERVER.MYLAB.COM

This command copies the remote SSH server's public key file HOSTKEY.PUB into a local directory as a file named KEY_22_MYSERVER_MYLAB_COM.PUB. Note that underscores replace the dots in the destination file.

If you copy these files manually, be sure to name the key files using this format. For example, if the server name is MYSERVER.MYLAB.COM, copy its HOSTKEY.PUB file to KEY_22_MYSERVER_MYLAB_COM.PUB in the appropriate directory.