The trusted host environment as an alternative to setting up
public-private SSH key pairs.
For automation or in a scripted environment in which these
types of calls are necessary, the trusted host network,
though still bearing some security risks, has advantages
over the public-private key pair scenario.
A trusted host network or trusted host authentication relies
primarily on preconfigured files that list a combination of users and hosts
that are allowed access.
There are two types of trusted-host authentication. The
older (such as for OpenSSH and SSH1) and weaker uses the clear-text protocol
commands (rsh, rcp, and rlogin);
checks the two files; and sets one keyword in the
sshd_config file:
/etc/hosts.equiv
~/.rhosts
SSH Protocol 2 does not support this method. Instead, for a
more secure trusted host network,
make the following changes in the /etc/ssh/sshd_config file
(which accepts host names or IP Addresses),
and configure the shosts.equiv and/or the .shosts files:
/etc/shosts.equiv
~/.shosts
To enable a trusted-host environment in the
/etc/ssh/sshd_config file for SSH Protocol 2, use:
PermitEmptyPasswords yes
AllowSHosts remoteclient.com
DenySHosts
For example, if you were on the server example.com and had
configured your /etc/shosts.equiv file as follows:
+remoteclient.com fsmythe
+secureserver.net sallyh
+192.168.100.12 fsmythe
-hackers.org james
you would allow user fsmythe trusted host authentication
from the remote sources remoteclient.com, 192.168.100.12, and secureserver.net
and user sallyh access from secureserver.net,
denying access from user james at the remote source
hackers.org. The trusted-host authentication and public-private SSH key pair
authentication methods are similar and to a greater end achieve the same
results.
