hosts.equiv, .rhosts -- lists of trusted hosts and remote users


The /etc/hosts.equiv and .rhosts files are used to determine remote user access to accounts on the local system. These files specify remote hosts and users that are considered to be ``trusted.'' Trusted users are allowed access to the local system without supplying a password.

Authentication is performed by the ruserok library routine (see rcmd(SLIB)).

The file /etc/hosts.equiv specifies system-wide behavior, but individual users may alter this behavior by maintaining a .rhosts file in their home directories.

Note that since these files bypass the standard password-based authentication mechanisms, care must be taken in creating and maintaining these files. Otherwise, system security may be compromised.

The remote authentication procedure determines whether a particular remote user from a particular remote host should be allowed to access the local system as a (possibly different) particular local user. /etc/hosts.equiv is checked first, followed by the .rhosts file in the home directory of the specified local user.

The format of hosts.equiv is a list of names, as in this example:

The .rhosts file has the same format as hosts.equiv. When user xxx executes rlogin or rcmd, the .rhosts file from xxx's home directory is conceptually concatenated onto the end of hosts.equiv for permission checking. In the special case when the user is not an individual user then only the .rhosts file in root's home directory is checked.

It is also possible to have two entries (separated by a single space) on a line of these files. For example:

   host1 user1
   host1 user2
In this case, if the remote host is equivalenced by the first entry, then the second entry specifies a user who is allowed to log in as the local user. Use of this form in /etc/hosts.equiv is discouraged, as it would allow the specified remote user to log in as any local user.

Negative entries may be specified by prefixing them with a minus sign (-). In this case, if the remote user or host matches the specification, access will be explicitly denied.

If NIS is enabled, netgroups (see netgroup(NF)) may be specified in either the host or user fields to match a number of hosts or users in one entry. (See ``Configuring the Network Information Service (NIS)'' in the Networking Guide for information on NIS, the Network Information Service.) The following form allows access from all hosts in the named netgroup:

+@ netgroup

When used in the ``username'' field, netgroups allow a group of remote users to access the system as a particular local user. The following form allows all of the users in the named netgroup from the named host (i.e. hostname) to access the system as the local user:

hostname +@ netgroup

The following form allows the users in netgroup2 from the hosts in netgroup1 to access the system as the local user:

+@ netgroup1 +@ netgroup2

Netgroups may also be used to deny access by prefixing them with a minus sign. The following example will disallow access by all of the users in the named netgroup from host host.

host -@ netgroup

If authentication fails, the programs rcmd(TC) and rcp(TC) will fail. rlogin(TC) will fall back to the standard password-based authentication.

NOTE: The .rhosts file must be owned by either the local user or root and writable only by the owner. Otherwise, it will be disregarded.

In addition, root's /.rhosts file must not be readable by other users (its permissions must be at most 600). Otherwise, root will not be able to log in from a remote machine.



See also

hosts.lpd(SFF), k5login(SFF), rcmd(TC), rcmd(SLIB), rlogin(TC)
© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003