January 07, 2009, 12:35 PM — There are several ways to establish a relationship between Unix systems such that you can issue commands on one system that are run on another and, in particular, allow you to do so without the encumbrance of entering a password. The primary reason why most
of us want to do this is, of course, so that we can issue commands in scripts that run non-interactively. Another reason is that, should you lose control of the root password on a system, you can reset it easily if you log into a system the host trusts and issue the passwd command from there.
The primary drawback to inter-host trust is that it runs the risk of being exploited. If someone gains root access on a system that other systems trust, they can take over the other systems as well. In practice, most trusted systems are set up with a much higher level of security and limited accounts to lessen the likelihood that no one who is not authorized can gain a position of power over the trusting systems.
Trust isn't confined to the root account. Users can set up their own inter-host trust such that they can issue commands on one system that are run under their username on another system and do so in scripts. A simple example might be a script that reports who is logged into each system in a group. If a developer, for example, is looking to work on a server that is not currently being used by other developers, he might want to scan the systems to see who is logged on where.
One trust mechanism is through use of the /etc/hosts.equiv file. This file sets up system-wide trust between systems. If the /etc/hosts.equiv on host1 contains "host2", then any user on host2 can issue rsh (remote shell) commands to host1.
If you add a "+" sign after a host name in the /etc/hosts.equiv file, users on the trusted system can issue commands on the trusting system as any user. For example, fred can run the command "rsh host1 -l barney mkdir /tmp/barney" and create a directory in /tmp that is both owned by and named "barney". Similarly, a "+ +" entry would allow any user on any host to do the same.
While a "lewis +" entry would allow users on lewis to run rsh commands on the local system under any username, a "+ lewis" entry would allow a user named lewis to run commands from any host.
The extra openness afforded by the + entries are rarely used because of the abuses they might invite. Fortunately, superuser access bypasses /etc/hosts.equiv altogether, so there are important limits on how far the abuse can go.
Access is generally denied by omitting hosts from the /etc/hosts.equiv file. You can explicitly deny access by preceding a hostname with a minus (-) sign, but individual users can still set up personal .rhosts files and override this setting.
You can also deny a specific user from a specific host by putting the equivalent of "host2 -barney" in /etc/hosts.equiv but, again, this restriction can be overridden by the user. If you get really serious about restricting users' .rhosts file, you could create a root-owned .rhosts file in their home directories, but this is a privilege you should take away from users without very good reason since it can greatly facilitate their work.
The rsh command is subject to CONSOLE constraints set up in /etc/default/login. If you intend to use rsh (or rlogin) to log in to a remote system without a password, your access will depend on whether you allow root login on other than the system console. Look for the CONSOLE line in the /etc/default/login file to determine whether root login is allowed on other than the console (#CONSOLE) or restricted to console (CONSOLE).
The order of processing rsh configuration files can be important to understanding how they work. The /etc/hosts.equiv file is read first when an rsh command is invoked, then the appropriate .rhosts file is read. If a user is blocked in /etc/hosts.equiv and allowed in his .rhosts file, he may still be able to run remote commands. This works on my Solaris systems. Run some tests on your systems if you need to be sure how the two files interact.
