Customizing the User Environment on the SSH Client Host

If both a Table of Contents and Search form are not displayed in separate frames along with this one, you may wish to redisplay this book in a frameset, beginning with the first page.

HP TCP/IP Services for OpenVMS Guide to SSH

Customizing the SSH Run-Time Environment

Customizing the User Environment on the Server Host

Customizing the User Environment on the SSH Client Host

During configuration, the SSH2_CONFIG. file is copied to TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2]. When the user invokes the SSH command, the SSH client process reads the file and creates the run-time version of the configuration parameters. If you want a different set of parameters (user specific), then you need to create your own version of the configuration file in the user SSH directory.

The SSH client loads this file and modifies the run-time version of the parameters accordingly. You can copy this file from a UNIX or an OpenVMS system and then edit it, or create a new file. The file can be in either STREAM_LF or variable-length format .

Copying the Server's Public Host Key to the Client

Any connection request from a client to an SSH server requires that the client obtain the server's public key. There are several ways to copy the server's public key to the client:

During SSH server configuration, the TCPIP$CONFIG configuration procedure creates the systemwide directory TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2.HOSTKEYS]. You can copy into this directory the host keys of all the remote servers to which you will connect from the client host.

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.

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

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

Copy the server's public key to this directory using the COPY/FTP command.

If you copy the keys, they must be in STREAM_LF record format and have proper access privileges, for example S:RWED,O:RWED,G:RE,W:R.

The key-generation utility creates all key files in STREAM_LF format. When the SSH server transfers the server's host key file to a client host, the resulting file is formatted correctly.

However, setting up the SSH environment sometimes requires that you manually copy public key files (whether host or user) between the SSH client and server hosts. For example, when using public-key authentication, the key file must be copied to an OpenVMS system. In these cases, FTP, for example, may create a variable-length record file. If this occurs, the user or system manager must convert this file to STREAM_LF format using the OpenVMS Convert utility. Failure to convert the file will cause key-processing errors.

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.

If the file is not found in either the systemwide or account-specific [.HOSTKEYS] directory, the first time you attempt to connect from your client to a remote SSH server, you are prompted to accept a copy of the server's public host key:

You can control this behavior using the StrictHostKeyChecking option in the client configuration file. This option accepts three possible values:

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

no -- Causes the SSH client to create the [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. For example:

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:[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.

Naming Conventions for the Server's Public Host Key

The server's public and host private key pair files by default are 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).

Note that hostname corresponds to the form of the SSH server name to which the SSH client connects, with underscores replacing dots if a qualified host name is used. For example, you connect to a 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.

Customizing the User Environment on the Server Host