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 /opt/tectia/etc/hostkeys directory. Host key files are not automatically put in the system-wide directory 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 you can either copy the keys manually from the server to the client or you can use the ssh-keydist-g3 tool from the client machine.

To copy the keys manually:

Select a client-side user whose $HOME/.ssh2/hostkeys will be the basis for the system-wide /opt/tectia/etc/hostkeys. The user should have administrative privileges, as placing the keys to the system-wide location requires them.
The same user account must also be used to maintain the system-wide /opt/tectia/etc/hostkeys later on if the host key on some server changes. 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 /opt/tectia/etc/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 Tectia client tools for z/OS 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 the key exchange part of the Secure Shell connection.
Once you have obtained all the host keys you wish to maintain in the system-wide location, place the keys to the system-wide location, for example by running the following commands:
```
# mkdir /opt/tectia/etc/hostkeys
# cp -p $HOME/.ssh2/hostkeys/* /opt/tectia/etc/hostkeys
```
Note that also the salt file ($HOME/.ssh2/hostkeys/salt) has to be copied so that Tectia client tools for z/OS is able to identify the hashed host keys. Also if multiple users contribute to the system-wide /opt/tectia/etc/hostkeys directory, they have to share the same salt file.

After creating the system-wide location for host keys, you can maintain it by using the ssh-keygen-g3 tool.

The following copy examples show the most frequently needed commands for host key storage maintenance. The commands use the user-specific hostkey storages ($HOME/.ssh2/hostkeys and possibly the $HOME/.ssh/known_hosts file) as the source. If keys are to be copied from a different source, you need to append an appropriate --hostkeys-directory or --hostkey-file option to the command.

To copy the key of a new host called 'alpha' from the user-specific hostkey storage to the system-wide directory, enter command:

# ssh-keygen-g3 --append=no --overwrite=no \
--copy-host-id alpha /etc/ssh2/hostkeys

In this case, because of --overwrite=no, if a key for server 'alpha' already exists, the command will fail and the key will not be updated.

To add additional keys to a known host, enter command:

# ssh-keygen-g3 --append=yes --copy-host-id alpha /etc/ssh2/hostkeys

To update the key of a known host, enter command:

# ssh-keygen-g3 --append=no --copy-host-id alpha /etc/ssh2/hostkeys

To remove a host from the known hosts list, enter command:

# ssh-keygen-g3 --hostkeys-directory /etc/ssh2/hostkeys \
--delete-host-id alpha

For more detailed information on the ssh-keygen-g3 tool, see ssh-keygen-g3(1).

To store the keys using ssh-keydist-g3:

Run ssh-keydist-g3 with the -g (alias for --accept-hostkeys-globally) option as a privileged user on the client, for example:
```
# ssh-keydist-g3 -N -i -g -A /tmp/newkeys.log host1 host2 host3#222
```
The -N option specifies that new host keys are accepted, and -A specifies a log file (in this example /tmp/newkeys.log) listing the accepted new host keys.
Substitute the appropriate list of host names as the command arguments.
The -i option specifies that the host keys are also stored using the IP addresses of the hosts. Transparent FTP tunneling and FTP-SFTP conversion require that the keys are stored using the IP address. However, the host keys are not automatically stored using the long host name. If you want to do also that, specify the long host name in addition to the short host name as an argument for ssh-keydist-g3.
After the transfer, verify the fingerprints of the keys from the log file /tmp/newkeys.log.

For more information on the ssh-keydist-g3 options, see ssh-keydist-g3(1).

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-keydist-g3 tool from the client machine.

To copy the keys manually:

As a server-side user, copy the /opt/tectia/etc/hostkey.pub file from the server as key_<port>_<hostname>.pub to the /opt/tectia/etc/hostkeys/ directory on the client.
You can do this as a non-privileged user on the server but you must be a privileged user, for example root, on the client.
Use secure means to transfer the file or verify that the fingerprint matches after the transfer with the ssh-keygen-g3 option -F (or --fingerprint), for example on Tectia Server on Unix:
```
$ ssh-keygen-g3 -F /etc/ssh2/hostkey.pub
```
On the client:
```
# ssh-keygen-g3 -F /opt/tectia/etc/hostkeys/key_<port>_<hostname>.pub
```
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_<port>_<hostname>.pub to all these different names.

To store the keys using ssh-keydist-g3:

Run ssh-keydist-g3 with the -F plain (-F is equal to --accepted-host-key-filename-format) and -g options as a privileged user on the client, for example:
```
# ssh-keydist-g3 -N -F plain -g -A /tmp/newkeys.log 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
```
After the transfer, verify the fingerprints of the keys from the log file /tmp/newkeys.log.

For more information on the ssh-keydist-g3 options, see ssh-keydist-g3(1).