OpenSSH/Cookbook/Host-based Authentication

Host-based authentication can apply to all users on a system or, using the Match directive, a subset. As mentioned it allows the hosts to authenticate on behalf of all or some of the systems users. It can be useful for managing computing clusters and other fairly homogenous pools of machines.

Three files on the server or target host must be modified to get host-based authentication working:

/etc/shosts.equiv - same syntax as rhosts.equiv, can point to netgroups

/etc/ssh/sshd_config - turn on host-based authentication

/etc/ssh/ssh_known_hosts - hold the identities of the clients

On the client, a single file must be configured:

/etc/ssh/ssh_config - allow clients to request host-based authentication

Server Configuration for host-based authentication

The /etc/shosts.equiv identifies which addresses are allowed to try authenticating. Keep this file simple and oriented to just the list of hosts. It provides only the first cut, anyway. For fine tuning, use sshd_config to set or revoke access for specific users and groups.

client1.example.org
192.168.0.102
client8.example.org -bull
@statcluster

Those hosts listed must also have their public keys in /etc/ssh/ssh_known_hosts on the server. There are three required data fields per line. First is the host name or ip address or comma separated list of them from shosts.equiv. Next is the key type, either ssh-rsa for RSA keys or ssh-dss for DSA keys. Third is the public key itself. Last, and optionally, can be a comment about the key.

desktop,192.168.0.102 ssh-rsa AAAAB3NzaC1yc2EAAAABIw ... qqU24CcgzmM=

Example excerpt from /etc/ssh/sshd_config allowing allow any user in the group turtles to let the hosts authenticate on their behalf:

Match Group turtles
   HostbasedAuthentication yes

If it is not possible for there to be a valid DNS entry resolving the hostname and address of the client, then it might be necessary to use a work around to make up for that lack. One choice is to use or set up a local name service using dnsmasq or some other easy option. Or another choice is to set sshd to accept the hostname information provided in the connection itself as being what it claims to be.

Excerpt from /etc/ssh/sshd_config to work around lack of DNS records for the client using the

HostbasedUsesNameFromPacketOnly directive:
   HostbasedUsesNameFromPacketOnly yes

Match Group turtles
   HostbasedAuthentication yes

Be prepared to run sshd standalone at debug level 3 (-D -ddd) and ssh at debug level 3 (-vvv) a few times to see what you missed. The mistakes have to be cleared up in the right order, so take it one step at a time.

debug3: /etc/ssh/sshd_config:19 setting Protocol 2
debug3: /etc/ssh/sshd_config:24 setting HostKey /etc/ssh/ssh_host_rsa_key
debug3: /etc/ssh/sshd_config:25 setting HostKey /etc/ssh/ssh_host_dsa_key
debug3: /etc/ssh/sshd_config:40 setting PermitRootLogin no
debug3: /etc/ssh/sshd_config:100 setting HostbasedAuthentication yes
debug3: /etc/ssh/sshd_config:101 setting HostbasedUsesNameFromPacketOnly yes
...
Failed hostbased for fred from 192.168.0.102 port 39653 ssh2
debug2: userauth_hostbased: authenticated 0
debug1: userauth-request for user fred service ssh-connection method hostbased
debug1: attempt 2 failures 1
debug2: input_userauth_request: try method hostbased
debug1: userauth_hostbased: cuser fred chost client1. pkalg ssh-rsa slen 271
debug2: userauth_hostbased: chost client1. resolvedname 192.168.0.102 ipaddr 192.168.0.102
debug2: stripping trailing dot from chost desktop.
debug2: auth_rhosts2: clientuser fred hostname client1 ipaddr desktop
...

Two more files may optionally be modified, if they are referred to from within shosts.equiv. Each line in the netgroup file consists of a net group name followed by a list of the members of the net group, specifically host, user, and domain.

 /etc/netgroup  default netgroup list
 /etc/netgroup.db       netgroup database, build from netgroup

??? However, these are mostly legacy from the old rhosts.

Local user host-based authentication

A list of allowed hosts is needed when host-based authentication is used. The list can be either local for the user or global. Individual users can have a local .shosts containing a list of trusted remote machines, or user-machine pairs, which are allowed to try host-based authentication.

.shosts must not writable by any group or any other users. Permissions set to 0644 should do it. The usage and format of .shosts is exactly the same as .rhosts, but allows host-based authentication without permitting login by insecure, legacy tools rlogin and rsh. The list is one line per host. The first column is obligatory and contains the name or address of the host permitted to attempt host-based authentication.

The second column is optional contains either a user name or netgroup name. But the user name checks using this method are not secure and restricting which specific users or groups may authenticate should be configured in sshd_config instead by using the Match Group directive.

See the manual page hosts.equiv(5) for more details on .shosts.

Client Configuration for Host-based Authentication

On the client, the global SSH client configuration file must be set to enable ssh-keysign(8). It is a helper application to access the local host keys and generate the digital signature required for host-based authentication

Excerpt from /etc/ssh/ssh_config on the client:

EnableSSHKeysign yes
HostbasedAuthentication yes

The Host directive in ssh_config(5) can be used to further constrain configuration specifics to a particular server is used.