next up previous contents
Next: The Network Information System Up: Various Network Applications Previous: Remote Procedure Call

Configuring the r Commands


There are a number of commands for executing commands on remote hosts. These are rlogin, rsh, rcp and rcmd. They all spawn a shell on the remote host and allow the user to execute commands. Of course, the client needs to have an account on the host where the commmand is to be executed. Thus all these commands perform an authorization procedure. Usually, the client will tell the user's login name to the server, which in turn requests a password that is validated in the usual way.

Sometimes, however, it is desirable to relax authorization checks for certain users. For instance, if you frequently have to log into other machines on your LAN, you might want to be admitted without having to type your password every time.

Disabling authorization is advisable only on a small number of hosts whose password databases are synchronized, or for a small number of privileged users who need to access many machines for administrative reasons. Whenever you want to allow people to log into your host without having to specify a login id or password, make sure that you don't accidentally grant access to anybody else.

    There are two ways to disable authorization checks for the r commands. One is for the super user to allow certain or all users on certain or all hosts (the latter definitely being a bad idea) to log in without being asked for a password. This access is controlled by a file called /etc/hosts.equiv. It contains a list of host and user names that are considered equivalent to users on the local host. An alternative option is for a user to grant other users on certain hosts access to her account. These may be listed in the file .rhosts in the user's home directory. For security reasons, this file must be owned by the user or the super user, and must not be a symbolic link, otherwise it will be ignored.gif

When a client requests an r service, her host and user name are searched in the /etc/hosts.equiv file, and then in the .rhosts file of the user she wants to log in as. As am example, assume janet is working on gauss and tries to log into joe's account on euler. Throughout the following, we will refer to Janet as the client user, and to Joe as the local user. Now, when Janet types

on gauss, the server will first check hosts.equivgif if Janet should be granted free access, and if this fails, it will try to look her up in .rhosts in joe's home directory.

The hosts.equiv file on euler looks like this:

An entry consists of a host name, optionally followed by a user name. If a host name appears all by itself, all users from that host will be admitted to their local accounts without any checks. In the above example, Janet would be allowed to log into her account janet when coming from gauss, and the same applies to any other user except root. However, if Janet wants to log in as joe, she will be prompted for a password as usual.

If a host name is followed by a user name, as in the last line of the above sample file, this user is given password-free access to all accounts except the root account.

The host name may also be preceded by a minus sign, as in the entry ``-public''. This requires authorization for all accounts on public, regardless of what rights individual users grant in their .rhosts file.

The format of the .rhosts file is identical to that of hosts.equiv, but its meaning is a little different. Consider Joe's .rhosts file on euler:

The first entry grants joe free acess when logging in from, but does not affect the rights of any other account on euler or chomp. The second entry is a slight variation of this, in that it grants janet free access to Joe's account when logging in from gauss.

Note that the client's host name is obtained by reverse mapping the caller's address to a name, so that this feature will fail with hosts unknown to the resolver. The client's host name is considered to match the name in the hosts files in one of the following cases:



next up previous contents
Next: The Network Information System Up: Various Network Applications Previous: Remote Procedure Call

Andrew Anderson
Thu Mar 7 23:22:06 EST 1996