Finally, I mention 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 (
rlogin); checks the two files; and sets one keyword in the sshd_config file:
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:
To enable a trusted-host environment in the /etc/ssh/sshd_config file for SSH Protocol 2, use:
For example, if you were on the server example.com and had configured your /etc/shosts.equiv file as follows:
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. Table 1 provides a side-by-side comparison of the two authentication methods.
Table 1. Comparison of private-public SSH key pairs with trusted-host configuration
|Private-public key pair
|Authenticate by IP address
|Authenticate by host name
|Use other public key features
|Authenticate by remote user name
|Allow wildcards in host names and IP addresses
|Passphrase is necessary for login access
|Breaks on IP address or host name change
|Configuration required on the server and client
|Useful for automated tasks or scripting needs
To those admins who are scoffing right now at the thought of allowing a trusted host authentication system using password-less remote SSH access on their network, consider the downside of public-private key pairs when using a script for remote SSH functionality:
- If a server host name or IP address changes, the public-private key pair configuration will break because of the cached known hosts. The old entry will need to be removed in the .ssh/known_hosts file and the SSH remote host name and/or IP address re-cached again. This will break scripts dependant on the private-public key pair.
- Private-public key pair authentication requires both client and server configuration. If an SSH public key changes or the pair is regenerated, all of the remote hosts will need the new public key in their authorized_keys file.
- If the permissions of the .ssh/ folder or private or public key files themselves change, it could prevent the SSH password-less access from occurring. To disable strict file and directory permissions checking, set the keyword
nowithin /etc/ssh/sshd_config file.
- There is no centralized way to revoke a key once a key pair has been generated or to know exactly to whom the key has been distributed.
SSH is a powerful and secure network utility that countless users worldwide use for numerous tasks. Offered as a safe and secure alternative to the clear-text protocols such as telnet and the
r* series command and with multiple offerings of freely distributable SSH clients and servers, SSH is difficult to beat. Used widely in many networks for mass remote monitoring, system maintenance, remote system auditing, reporting, and automation within scripting technologies, it appears that SSH is here to stay and will continue to evolve.