Host-based authentication mimics the old rhosts authentication that was used with Unix tools such as rsh and rcp to control access to systems based on the address of the remote host. The difference with the old way and the current host-based authentication is that in Secure Shell v2 strong cryptography is used to perform the host identity check.

The old way of identifying the host with its name or IP address is very insecure. It was based on the assumption that DNS names and IP addresses could not easily be tampered with. DNS services were typically hosted on servers controlled by system administrators, on ports where ordinary users could not start services. This assumption, however, is no longer valid, since personal computers have become much more common, and many more people now have the opportunity to set up DNS services or programs that capture and alter network traffic. Since DNS lookups and the portion of an IP packet that contains the IP address are not encrypted, they are vulnerable to interception and alteration.

Host-based authentication in the SecSh v2 protocol does not need to rely solely on the DNS information. In fact, in environments where NAT (Network Address Translation) is used, it is usually necessary to disable the DNS matching in server configuration. Instead, the client host is authenticated with a public key pair, which is typically the host key pair or the host certificate pair of the SSH Tectia Server on the client side.

Host-based authentication is actually similar to public-key authentication. On the server side, the public key is required to identify the client host, or in case certificates are used, the identification is based on the contents of the host certificate as in server authentication with certificates. On the client side, the difference compared to user public-key authentication is that the user does not have direct access to the private key. Instead, a small setuid program is used to sign the challenge. This program is able to access the root-owned private key of the client host. The program also checks that the user is signing the challenge with correct information; the server uses this information, which contains the client-side username and hostname, when it decides whether the user is authorized to log in to the requested account. Host-based authentication with certificates also makes it possible to have scalable user authorization in the SSH Tectia Server configuration. It is possible, for example, to allow login to particular user account(s) only from particular client host(s).

The major drawback with host-based authentication is that it effectively puts the server host to the same trust level as the client host. This is usually not a problem if both the client and server machines are in a controlled environment and administered by trusted people. While both user public-key authentication and host-based authentication rely on the integrity of the private key on the client side, host-based authentication relies also heavily on the integrity of the user account management and the initial user authentication to the client-side system. In host-based authentication, a client-side user that has the same name as the server-side user is considered equivalent. Therefore, for example, denying root login with host-based authentication is usually prudent. Otherwise if the client host is breached, the attacker has immediate root privileges in all participating hosts (requiring strong authentication for root is usually wise in any case, however).