Recipe 6.8 Authenticating by Trusted Host

6.8.1 Problem

You want to authenticate between an OpenSSH client and server using hostbased or "trusted host" authentication.

6.8.2 Solution

Suppose you want to allow the account [email protected] access to [email protected]. Then:

6.8.3 Discussion

This recipe applies only to SSH-2 protocol connections. OpenSSH does support an SSH-1 type of trusted-host authentication (keyword RhostsRSAAuthentication) but as we've said before, we strongly recommend the more secure SSH-2.

Before using hostbased authentication at all, decide if you truly need it. This technique has assumptions and implications unlike other SSH user-authentication mechanisms:

Strong trust of the client host

The server must trust the client host to have effectively authenticated the user. In hostbased authentication, the server does not authenticate the user, but instead authenticates the client host, then simply trusts whatever the client says about the user. If the client host is compromised, all accounts on the server accessible via hostbased authentication are also immediately vulnerable.

Weak authorization controls

Individual users on the server can override hostbased restrictions placed by the sysadmin. This is why the server's IgnoreRhosts option exists.

If all you want is automatic authentication (without a password), there are other ways to do it, such as public-key authentication with ssh-agent [Recipe 6.9] or Kerberos. [Recipe 4.14]

If you decide to use hostbased authentication for an entire user population, read the relevant sections of SSH, The Secure Shell: The Definitive Guide (O'Reilly), which detail various subtleties and unexpected consequences of this mechanism.

Speaking of subtleties, the issue of the client's canonical hostname can be tricky. The SSH server will look up the client's host key by this name, which it gets from the client's IP address via the gethostbyname library function. This in turn depends on the naming service setup on the server side, which might consult any (or none) of /etc/hosts, NIS, DNS, LDAP, and so on, as specified in /etc/nsswitch.conf. In short, the client's idea of its hostname might not agree with the server's view.

To learn the client's canonical hostname as sshd will determine it, run this quick Perl script on the server:

#!/usr/bin/perl
use Socket;
print gethostbyaddr(inet_aton("192.168.0.29"), AF_INET) . "\n";

where 192.168.0.29 is the IP address of the client in question. You can also run this as a one-liner:

$ perl -MSocket -e 'print gethostbyaddr(inet_aton("192.168.0.29"),AF_INET)."\n"'

You might be tempted to run the host program instead (e.g., host -x 192.168.0.29) on the server, but the output may be misleading, since host consults only DNS, which the server's naming configuration might not use. If the SSH server cannot get any name for the client's address, then it will look up the client's host key in its known-hosts file by address instead.

And that's not all. The canonical hostname issue is further complicated, because the client independently identifies itself by name within the SSH hostbased authentication protocol. If that name does not match the one determined by the SSH server, the server will refuse the connection. There are many reasons why these names may not match:

• The client is behind a NAT gateway

• Names are simply not coordinated across the hosts

• Your SSH connection is going through a proxy server

• The SSH client host is multi-homed

If this problem occurs, you'll see this server error message in your syslog output:

userauth_hostbased mismatch: client sends name1.example.com,
but we resolve 192.168.0.72 to name2.example.com

The configuration keyword HostbasedUsesNameFromPacketOnly will relax this restriction in the SSH server:

/etc/ssh/sshd_config:
HostbasedUsesNameFromPacketOnly yes

This means that sshd uses only the self-identifying hostname supplied by the client in its hostbased authentication request, to look up the client's public host key for verification. It will not insist on any match between this name and the client's IP address.

The client-side, per-user configuration files in ~/.ssh may be used instead of the global ones, /etc/ssh/ssh_config and /etc/ssh/ssh_known_hosts. There is no harm in placing keys into the global list: it does not by itself authorize logins (an authorization task), but only enables authentication with the given client host.

You can authorize hostbased authentication globally on the server by placing the client hostname into /etc/shosts.equiv. This means that all users authenticated on the client host can log into accounts with matching usernames on the server. Think carefully before doing this: it implies a high level of inter-host trust and synchronized administration. You should probably customize the shosts.equiv file using netgroups to restrict hostbased authentication to user accounts; see the sshd manpage.

Lastly, note that earlier versions of OpenSSH required the ssh client program to be setuid for hostbased authentication, in order to access the client host's private key. But in the current version, this function has been moved into a separate program, ssh-keysign; the ssh program itself need no longer be setuid.

6.8.4 See Also

sshd(8), sshd_config(5), gethostbyname(3).