Wednesday, July 27, 2011

Creating a trusted host environment using SSH


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 (rshrcp, 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. 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 

SSH aspectTrusted hostPrivate-public key pair
Authenticate by IP addressYesYes
Authenticate by host nameYesYes
Use other public key featuresNoYes
Authenticate by remote user nameYesNo
Allow wildcards in host names and IP addressesNoYes
Passphrase is necessary for login accessNoNo
Breaks on IP address or host name changeSometimesYes
Configuration required on the server and clientNoYes
Useful for automated tasks or scripting needsYesYes

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 StrictModes to 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.

No comments:

Post a Comment