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


Chapter 9 Managing Host Authentication

When an SSH client attempts to connects to an SSH server, the server host authenticates itself to the client. If the client cannot authenticate the server, the client refuses to continue and disconnects. The server host can authenticate itself using public keys, certificates, or both, allowing for smooth migration from public keys to certificates.

SSH server hosts use cryptographic authentication and each server has a unique cryptographic key pair (a public key and a private key) that identifies the server. Whenever a Secure Shell client connects to a Secure Shell server, the server authenticates itself to the client cryptographically. This ensures that encryption and integrity protection are provided end-to-end between the client and the intended server, and eliminates the possibility to perform certain cryptographic attacks, especially man-in-the-middle attacks.

In order for the cryptographic authentication to work, the client must know the server's public key so that it can securely authenticate the server. The public key of the server must be distributed to the client hosts. The private key of the server is never sent anywhere outside the server computer, but is used by the server to create a digital signature that can then be verified by the client using the public key.

Host key authentication is an alternative in small and medium-size networks, where simple public-key authentication is used without certificates. Host key authentication also makes it feasible to update the host keys automatically.

In large environments, the distribution of server public keys starts to become cumbersome even with Tectia Manager. Each host key consumes about a kilobyte of disk space, thus 1000 host keys will consume about a megabyte of disk space on each client machine.

As all host keys are sent to every machine, the time needed to distribute a new host key to all hosts grows linearly with the number of hosts, and the time needed to redistribute all host keys to all hosts grows with the square (N2) of the number of hosts. Even though host key distribution is very fast, performing millions of key transfers to thousands of machines over the network can take several hours and results in gigabytes of network traffic.

These issues pose a limit on the number of host keys that can be handled in practice as the environment grows. There are two approaches to make the server authentication scale beyond a few thousand hosts; we recommend the first option:

  • Use full public-key infrastructure (PKI) for server host authentication, as certificate management saves time and network load. Only the certificate of the Certification Authority (CA) who has issued the server certificates needs to be distributed to client hosts. You can apply the built-in CA of Tectia Manager or a third-party PKI solution for server host identity management.

  • Install more than one instance of Tectia Manager, and divide the hosts into logical management environments (for example, by division), so that only a few thousand hosts are under each management system.




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