Authenticating Remote Server Hosts
Server authentication is done during Diffie-Hellman key exchange through a
single public-key operation. When public-key authentication is used to
authenticate the server, the first connection is very important. During the
first connection the client will display a message similar to
the following:
Host key not found from database.
Key fingerprint:
xezop-fomas-lifot-pisoc-zyvik-hutoz-bafaf-zapyc-lubev-riked-dexax
You can get a public key's fingerprint by running
% ssh-keygen2 -F publickey.pub
on the keyfile.
Are you sure you want to continue connecting (yes/no)?
|
At this point, you should verify the validity of the fingerprint, for
example by contacting the administrator of the remote host computer
(preferably by telephone) and asking the administrator to verify that the key
fingerprint is correct. If the fingerprint is not verified, it is
possible that the server you are connecting to is not the intended one
(this is known as a man-in-the-middle attack).
After verifying the fingerprint, it is safe to continue connecting. The
server public key will then be stored on the client machine. The location
depends on the client implementation (on z/OS USS it is the
user's $HOME/.ssh2/hostkeys directory).
Host Key Storage Formats
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. A salt is included in the hash
calculations. The value of the salt is stored in the file salt
in the same directory as the host keys ($HOME/.ssh2/hostkeys).
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 storage format can be controlled with the HostKeyFormat
option of the ssh2_config configuration file. The argument must
be plain or hashed (default).
If you are adding the keys manually, the keys should be named with the
key_<port>_<host>.pub pattern, where
<port> is the port the Secure Shell server is running on
and <host> is the hostname you use when connecting to the
server (for example, key_22_alpha.example.com.pub).
If both the hashed and plaintext format keys exist, the hashed format
takes precedence.
Note that the identification is different based on the host and port the
client is connecting to. For example, the short hostname alpha
is considered different from the fully qualified domain name
alpha.example.com. Also a connection with an IP, for example
10.1.54.1, is considered a different host, as is a connection
to the same host but different port, for example
alpha.example.com#222.
After the first connection, the local copy of the server public key will
be used in server authentication.
Using the System-Wide Host Key Storage
If a host key is not found in the user-specific host key directory, it
is next searched from the /etc/ssh2/hostkeys directory. Host
key files are not automatically put in these directories but they have
to be updated manually by the system administrator.
Storing Keys in the Hashed Format
To obtain and store hashed remote host keys in the system-wide storage:
- Select a client-side user whose
$HOME/.ssh2/hostkeys will
be the basis for the system-wide /etc/ssh2/hostkeys. The user
should have administrative privileges, as placing the keys to the
system-wide location requires them.
This user must also be used to maintain the system-wide
/etc/ssh2/hostkeys later on if the host key on some server
changes or new servers are added. The process is to maintain the user's
host keys in the $HOME/.ssh2/hostkeys directory and then
replicate the changes to the system-wide /etc/ssh2/hostkeys
directory.
- Make sure that the
$HOME/.ssh2/hostkeys directory is
empty when obtaining the keys for the first time, or that the saved host
keys are intentional.
If you need to obtain new keys later, the same
$HOME/.ssh2/hostkeys/salt file has to be used.
- Connect with SSH Tectia Client to the remote server, verify the
fingerprint, and save the key.
Repeat this step as many times as there are remote servers. Note that
you do not have to complete the user authentication, only key exchange
part of the Secure Shell connection.
- Once all host keys you wish to maintain in the system-wide
location have been obtained, place the keys to the system-wide location,
for example by running the following commands:
> mkdir /etc/ssh2/hostkeys
> cp -p $HOME/.ssh2/hostkeys/* /etc/ssh2/hostkeys
Note that also the $HOME/.ssh2/hostkeys/salt file has to be
copied so that SSH Tectia Client is able to identify the hashed host
keys. Also if multiple users contribute to the system-wide
/etc/ssh2/hostkeys, they have to share the same salt file.
Storing Keys in the Plain Format
To obtain and store traditional (plain) remote host keys in the system-wide
storage you can either copy the keys manually from the server to the client
or you can use the ssh-keydist2 tool from the client machine. To
copy the keys manually:
- As a server-side user, copy the
/etc/ssh2/hostkey.pub
file from the server as key_<port>_<host>.pub to
the /etc/ssh2/hostkeys directory on the client.
You can do this as a non-privileged user on the server but you must
be privileged user, for example root, on the client.
Note that the identification is different based on the host and port the
client is connecting to. Also connection with IP is considered a
different host as well as connection to same host but different port.
You can copy the same traditional key
key_<port>_<host>.pub to all these different names.
- Use secure means to transfer the file, or verify the fingerprint
matches after the transfer with the
ssh-keygen2 option -F,
for example on the server:
$ ssh-keygen2 -F /etc/ssh2/hostkey.pub
On the client:
# ssh-keygen2 -F /etc/ssh2/hostkeys/key_<port>_<host>.pub
To store the keys using ssh-keydist2:
- Run
ssh-keydist2 with the -F plain and -g
options as a privileged user on the client, for example:
> ssh-keydist2 -N -F plain -i -g host1 host2 host3#222
Substitute the appropriate list of host names as the command arguments. In
the example above, the following host keys are fetched:
key_22_host1.pub
key_22_host2.pub
key_222_host3.pub
The -i option specifies that the host keys are also stored using
the IP addresses of the hosts (for example,
key_22_192.168.0.1.pub). However, the host keys are not
automatically stored using the long hostname. If you want to do also that,
specify the long hostname in addition to the short hostname as an argument
for ssh-keydist2.
- After the transfer, verify the fingerprints of the keys with the
ssh-keygen2 option -F.
For more infromation on the ssh-keydist2 options, see Appendix
ssh-keydist2.
Using OpenSSH Host Keys
OpenSSH keeps the public key data of known server hosts in the
$HOME/.ssh/known_hosts file.
The SSH Tectia Server for IBM z/OS client components cannot read this file. However, you can
convert the file to separate *.pub files with the
--import-ssh1-known-hosts-file option of the ssh-keygen2 command.
For example, running the following command in the $HOME/.ssh
directory converts the known_hosts file and saves the keys in
the same directory:
$ ssh-keygen2 --import-ssh1-known-hosts-file known_hosts
After converting the keys, move the *.pub files to the
$HOME/.ssh2/hostkeys directory.
The host key(s) in the OpenSSH known_hosts file must be in
plaintext format. OpenSSH-style hashed host keys are not supported.
For more information on the ssh-keygen2 options, see the
ssh-keygen2 man page (Appendix ssh-keygen2).
