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


Authenticating Remote Server Hosts

Remote Secure Shell servers are authenticated using either traditional public-key authentication or certificate authentication.

In public-key authentication the client trusts the server if it has a private key that matches one of the public keys in the global hostkeys directory (/opt/tectia/etc/hostkeys) or in the user's hostkeys directory ($HOME/.ssh2/hostkeys). When a server presents a key that is not in the hostkeys directories, the user verifies the fingerprint of the remote server's public key. When the user has approved the public key, it is stored in the user's hostkeys directory and will be used automatically thereafter.

The verification step requires user interaction, so even for users that are set up to run client programs unattended (Under MVS), the first connection must be done by a person who logs in as the user, accesses the remote server, and goes through the fingerprint check dialog. The same steps must be repeated if the remote host's key is changed.

Optionally, the ssh-keyfetch tool can be used for storing the remote server keys before the connections are made. See ssh-keyfetch(1).

For more information on server authentication using public keys, see Server Authentication with Public Keys in File.




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