The key pair used for server authentication is defined on the
server in the
file with the
HostkeyFile <private hostkey>
PublicHostKeyFile <public hostkey>
During the setup process, one RSA key pair (with the file names
) is generated and
stored in the
directory. By default this key
pair is used for server authentication. Make sure that only the user running
sshd2 has access to the private key.
In SSH Tectia Server, each server daemon can have multiple host keys. The daemon
supports one DSA and one RSA key pair. You could have, for example, the
following set of parameters in your
# RSA key
# DSA key
Both keys are stored in memory when the
started, which means that either one of them can be used to authenticate
By default, the server uses a public key with the filename of the
private key plus the extension
keyword has to be defined only if the public-key file is stored with a
Generating the Server Host Key Pair
The host public-key pair (1536-bit RSA) is generated during the setup of
SSH Tectia Server (Section Running the Setup Script).
You only need to regenerate it if you want to change your host key pair.
SSH Tectia Server for IBM z/OS includes a program that generates a key pair,
which is located in
Generate the key pair for the server in such a way that the private key
has no passphrase (option
-P). The server will then start up
without any operator interaction to enter a passphrase. Protect the key
with file system access rules. The private key (
must be accessible only by the
ssh-keygen2 tool can be used to generate the key pair.
To (re)generate the host key, perform the following tasks:
- Switch to the
SSHD2 user (if not already).
ssh-keygen2 to generate the host key, for example:
> /usr/lpp/ssh2/bin/ssh-keygen2 -P /etc/ssh2/hostkey
This will generate a 2048-bit DSA key pair without a passphrase and store
/etc/ssh2. For more information on the key generation
options, see the
ssh-keygen2 man page (Appendix ssh-keygen2).
- Restart the server as instructed in Section
Starting the Server.
Notifying the Users of the Host Key Change
Administrators that have other users connecting to their server should
notify the users of the host key change. If you do not, the users will
receive a warning the next time they connect because the host key the
users have saved on their disk for your server does not match the host
key now being actually provided by your server. The users may not
know how to respond to this error.
You can run the following to generate a fingerprint for your new public
host key which you can provide to your users via some unalterable method
(for example, by a digitally signed e-mail or by displaying the
fingerprint on secured bulletin board):
> /usr/lpp/ssh2/bin/ssh-keygen2 -F hostkey.pub
When the users connect and receive the error message about the host key having
changed, they can compare the fingerprint of the new key with the fingerprint
you have provided in your e-mail, and ensure that they are connecting to the
sshd2 daemon. Inform your users to notify you if the fingerprints do not
match, or if they receive a message about a host key change and do not
receive a corresponding message from you notifying them of the change.
This procedure can help ensure that you do not become a victim of a
man-in-the-middle attack, as your users will notify you if the
host key fingerprints do not match. You will also be aware if the
users encounter host key change messages when you have not regenerated
your host key pair.
If you want to avoid the risk associated with the first connection, you can
do one of the following:
- As an administrator of both the client and server machines, you can
copy the server public key in advance to the
directory on the client computer as
<hostname> is the hostname the client uses when it
connects to the server).
In this case, manual fingerprint check is not needed, and you can also
keyword in the
file on the client to
ssh2 will refuse to connect if the server's public key is not
- The server administrator can also send the public host key to the
users via an unalterable method. The users can save the key in their
$HOME/.ssh2/hostkeys directory as
key_22_<hostname>.pub. If all remote host keys are received
in this manner, the
StrictHostKeyChecking option can be enabled on