HP UX : Creating a trusted host environment using SSH

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.