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:
Create the subdirectory [.HOSTKEYS] in the user's SSH directory.
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:
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.
