hosts.equiv(4)

NAME

hosts.equiv, .rhosts − security files authorizing remote hosts and users on local host

DESCRIPTION

/etc/hosts.equiv and files named .rhosts in users’ home directories specify remote hosts and users that are “equivalent” to the local host or user. Users from equivalent remote hosts are permitted to access a local account using remsh or rcp or to rlogin to the local account without supplying a password (see remsh(1), rcp(1), and rlogin(1)). The security defined in hosts.equiv is implemented by the library routine ruserok() (see ruserok(3N)). In the following, hosts.equiv means either /etc/hosts.equiv or a file .rhosts in a local user’s home directory. Note that .rhosts must be owned either by the user in whose home directory it is found, or by the super-user, and must not be a symbolic link. /etc/hosts.equiv defines system-wide equivalency, whereas a user’s .rhosts defines equivalency between that user and remote users to whom that user chooses to allow or deny access.

Each line of hosts.equiv can consist of:

• A blank line.

• A comment, beginning with a #.

• A host name, consisting of a string of any printable characters other than white space, new-line, or #.

• A host name, followed by white space, followed by a user name.

In order for a user to be granted access, both the remote host name and user name must “match” an entry in hosts.equiv. /etc/hosts.equiv is searched first. If a match is found, access is permitted. If not, it searches the .rhosts file if it exists in the local user’s home directory. If the local user is the super-user, /etc/hosts.equiv is ignored.

A host name or user name matches the corresponding field in an entry in hosts.equiv in one of the following ways:

Literal match:
A host name in hosts.equiv can literally match the official host name (not an alias) of the remote host. A user name in hosts.equiv can literally match the remote user name. If there is no user name in the hosts.equiv entry, the remote user name must literally match the local user name.

Domain-extended match:
The remote host name to be compared with entries in hosts.equiv is typically the official host name returned by gethostbyaddr() (see gethostbyaddr(3N)). In a domain naming environment, this is a domain-qualified name. If a host name in hosts.equiv does not literally match the remote host name, the host name in hosts.equiv with the local domain name appended may match the remote host name.

%: any active node in an HP cluster, including the cluster server, matches the host name % in hosts.equiv. It is assumed that the names of cnodes are all in the same domain.

-name: If the host name in hosts.equiv is of this form, and if name literally matches the remote host name or if name with the local domain name appended matches the remote host name, access is denied regardless of the user name. If the user name in hosts.equiv is of this form, and name literally matches the remote user name, access is denied. Even if access is denied in this way by /etc/hosts.equiv, access can still be allowed by .rhosts.

+: Any remote host name matches the host name + in hosts.equiv; any remote user matches the user name +.

+@netgroup_name
where netgroup_name is the name of a network group as defined in netgroup(4): If the host name in hosts.equiv is of this form, the remote host name (only) must match the specified network group according to the rules defined in netgroup(4) in order for the host name to match. Similarly, if the user name in hosts.equiv is of this form, the remote user name (only) must match the specified network group in order for the user name to match.

−@netgroup_name:
If the host name in hosts.equiv is of this form, and if the remote host name (only) matches the specified network group according to the rules defined in netgroup(4), access is denied. Similarly, if the user name in hosts.equiv is of this form, and if the remote user name (only) matches the specified network group, access is denied. Even if access is denied in this way by /etc/hosts.equiv, access can still be allowed by .rhosts.

EXAMPLES

1) /etc/hosts.equiv on hostA contains the line:

hostB

and /etc/hosts.equiv on hostB is empty. User chm on hostB can use remsh to hostA, or rlogin to account chm on hostA without being prompted for a password. chm will, however, be prompted for a password with rlogin, or denied access with remsh, from hostA to hostB.

If .rhosts in the home directory of user chm on hostB contains:

hostA

hostA chm

then user chm can access hostB from hostA.

2) hostA is in the domain arg.bob.com; hostB and hostC are in the domain oink.bob.com. .rhosts in the home directory of user chm on hostB contains:

hostC
hostA

User chm can access hostB from hostC, since hostC.oink.bob.com matches hostC with hostB’s local domain oink.bob.com appended. But user chm from hostA cannot access hostB, since hostA.arg.bob.com does not match hostA.oink.bob.com. In order for user chm to be able to access hostB from hostA, chm’s .rhosts file on hostB must contain:

hostA.arg.bob.com

since hostA is in a different domain.

3) .rhosts in the home directory of user chm on hostA contains:

hostB root

/etc/hosts.equiv on hostB contains the line:

hostA

However, there is no file .rhosts in the home directory of user chm on hostB. The user root on hostB can rlogin to account chm on hostA without being prompted for a password, but root on hostA cannot rlogin to account chm on hostB.

4) .rhosts in the home directory of user chm on hostA contains:

+
-hostB
+ root

User chm from any host is allowed to access account chm on hostA. User root from any host except hostB can access account chm on hostA.

5) /etc/hosts.equiv on hostA contains the lines:

+ -chm
hostBm

Any user from hostB except chm is allowed to access an account on hostA with the same user name.

However, if .rhosts in the home directory of user chm on hostA contains:

hostB

then user chm from hostB can access account chm on hostA.

6) /etc/hosts.equiv on hostA contains the line:

+@example_group

The network group example_group consists of:

example_group ( , ,EXAMPLE_DOMAIN)

If hostA is not running Network Information Service (NFS), user chm on any host can access account chm on hostA.

If hostA is running Network Information Service (NFS), and hostA is in the domain EXAMPLE_DOMAIN, user chm on any host, whether in EXAMPLE_DOMAIN or not, can access account chm on hostA.

However, if .rhosts in the home directory of user chm on hostA contains the line:

-@example_group

and hostA is either not running Network Information Service (NFS) or is in domain EXAMPLE_DOMAIN, no user chm on any host can access the account chm on hostA. If hostA is running Network Information Service (NFS) but is not in the domain EXAMPLE_DOMAIN, this line has no effect.

7) /etc/hosts.equiv on hostA contains the line:

The network group example_group consists of:

example_group (hostB, ,)

All users on hostB are denied access to hostA.

However, if .rhosts in the home directory of a user on hostA contains any of the following lines:

+@example_group chm
hostB chm
+ chm

then user chm on hostB can access that account on hostA.

WARNINGS

For security purposes, the files /etc/hosts.equiv and .rhosts should exist and be readable and writable only by the owner, even if they are empty. However, if the user’s home directory is mounted remotely via NFS, .rhosts must be readable by all. Otherwise, remshd and rlogind cannot read .rhosts, since they run as root, who normally does not have special privileges over an NFS mount (see remshd(1M) and rlogind(1M)).

The −l option to remshd and rlogind prevents any authentication based on .rhosts files for users other than the super-user.

AUTHOR

hosts.equiv was developed by the University of California, Berkeley.
The % extension was developed by HP.
The +, -name, +@netgroup_name, and -@netgroup_name extensions were developed by Sun Microsystems, Inc.

FILES

/etc/hosts.equiv
$HOME/.rhosts

Museum

Related Articles