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


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 display a fingerprint of 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):

$ /opt/tectia/bin/ssh-keygen-g3 -F

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 correct 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 global hostkeys directory on the client computer as key_22_<hostname>.pub (where <hostname> is the hostname the client uses when it connects to the server). The location of this directory depends on the operating system:

    • On Tectia client tools for z/OS: /opt/tectia/etc/hostkeys

    • On Tectia Client on Unix: /etc/ssh2/hostkeys

    • On Tectia Client on pre-Vista Windows: "C:\Documents and Settings\All Users\Application Data\SSH\HostKeys"

    • On Tectia Client on Windows Vista and later Windows versions: "C:\ProgramData\SSH\HostKeys"

    In this case, manual fingerprint check is not needed, and you can also set the strict-host-key-checking option in the ssh-broker-config.xml file on the client to yes. After this, Tectia Client will refuse to connect if the server's public key is not in the hostkeys directory.

  • 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 strict-host-key-checking option can be enabled on the client.


Highlights from the SSH.COM blog:

  • Cryptomining with the SSH protocol: what big enterprises need to know about it

    Cryptomining malware is primarily thought of as targeting desktops and laptops and is used to hijack system resources to mine cryptocurrency.
    Read more
  • SLAM the door shut on traditional privileged access management

    Did you know that something as trivial-sounding as granting access for your developers or third parties to a product development environment can throw a gorilla-sized monkey wrench into your operations and productivity?
    Read more
  • We broke the IT security perimeter

    Everyone understands the concept of a security perimeter. You only gain access if you are identified and authorized to do so.
    Read more