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
Esther Schindler
If the comments are ugly, the code is ugly
claird
SVG a graphics format for 21st century
pasmith
Take Chrome OS for a test spin
Sandra Henry-Stocker
Solaris Tip: Have Your Files Changed Since Installation?
jfruh
Android fragments vs. the iPhone monolith
mikelgan
What Gizmodo missed about the Pro WX Wireless USB disk drive
Where Google Chrome security fails: the password
I heard mention that the Chrome OS will have some sort of encryption available a la bitlocker. If it's possible to encrypt personal data using another password or key, then it may have potential for very secure data.... And Ubuntu has an 'encrypt home directory' option, perhaps google should follow suit.
- Dann
Join the conversation here
Quick, practical advice for IT pros. Made fresh daily.
Want to cash in on your IT savvy? Send your tip to tips@itworld.com. If we post it, we'll send you a $25 Amazon e-gift card.
What a HORRID article
What the @#$%^& is this author thinking?!?! Writing such an article promoting the "capabilities" of the r-family of protocols in 2009! This belongs in 1985. NEVER use any of these protocols for ANY reason -- they are heinously insecure and expose any system networked to the outside world to a myriad of vulnerabilities (can you say 'clear text passwords'?)Google on 'ssh'. It's your modern Swiss-army knife that will do ANY of these tasks and more in a secure fashion. And if you have trust and need to forgo passwords, have a read on 'known hosts' and the ssh configuration files.
Repeat: NEVER use ANY of the obsoleted r-family protocols -- the Internet isn't honest anymore.
I second the first post!
I second the first post! This guy hasn't a clue what he is talking about. They shouldn't even be packaging that old shit anymore without crazy warnings. SSH is all you need or want.Outdated
I agree with the first two posts in that no one in their right mind should use any of the r-protocols on the public Internet. However, the article is an interesting look at how UNIX systems once operated, and it may very well be useful to someone dealing with a legacy system, or, for that matter, just a couple systems that are newer but relatively isolated from the outside world (even in a different segment of an internal network).