Your browser does not allow storing cookies. We recommend enabling them.

SSH Tectia 
PreviousNextUp[Contents] [Index]

    About This Document >>
    Installing SSH Tectia Server for IBM z/OS >>
    Getting Started with SSH Tectia Server for IBM z/OS >>
    Configuring the Server >>
    Configuring the Client >>
    Authentication >>
        Using the z/OS System Authorization Facility
        Server Authentication with Public Keys in File >>
            Server Configuration
            Client Configuration
        Server Authentication with Certificates >>
        User Authentication with Passwords
        User Authentication with Public Keys in File >>
        User Authentication with Certificates >>
        Host-Based User Authentication >>
        User Authentication with Keyboard-Interactive >>
        Distributing Public Keys Using the Key Distribution Tool >>
    Transferring Files >>
    Tunneling >>
    Troubleshooting SSH Tectia Server for IBM z/OS >>
    Advanced Information >>
    Man Pages >>
    Log Messages >>

Client Configuration

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:
You can get a public key's fingerprint by running
% ssh-keygen2 -F
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, 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).

HostKeyFormat              plain

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,

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 Also a connection with an IP, for example, is considered a different host, as is a connection to the same host but different port, for example

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.

To obtain and store hashed remote host keys in the system-wide storage:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

For examples on storing multiple host keys using the hostkey tool, see Appendix Example of Distributing Keys.

To obtain and store traditional (plain) remote host keys in the system-wide storage:

  1. As a server-side user, copy the /etc/ssh2/ 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.

  2. 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/

    On the client:

    # ssh-keygen2 -F /etc/ssh2/hostkeys/key_<port>_<host>.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>_<host>.pub to all these different names.

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).

PreviousNextUp[Contents] [Index]

[ Contact Information | Support | Feedback | SSH Home Page | SSH Products ]

Copyright © 2007 SSH Communications Security Corp.
This software is protected by international copyright laws. All rights reserved.
Copyright Notice




What to read next:

  • Reduce Secure Shell risk. Get to know the NIST 7966.

    The NISTIR 7966 guideline from the Computer Security Division of NIST is a direct call to action for organizations regardless of industry and is a mandate for the US Federal government.
    Download now
  • ISACA Practitioner Guide for SSH

    With contributions from practitioners, specialists and SSH.COM experts, the ISACA “SSH: Practitioner Considerations” guide is vital best practice from the compliance and audit community.
    Download now