Unix as a Second Language

Unix tip: Inter-host trust on Unix, part 1

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.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world