HOSTS.EQUIV(4)HOSTS.EQUIV(4)NAME
hosts.equiv, rhosts - trusted hosts by system and by user
DESCRIPTION
The remote login and shell servers use an authentication scheme based on
``trusted hosts.'' The /etc/hosts.equiv file contains a list of hosts
that are considered trusted and under the same administrative control.
When an rlogin(1C), rcp(1C), rdist(1C), or rsh(1C) request is received
from a host listed in hosts.equiv and when the targeted user account is
listed in the /etc/passwd file, then the remote access is allowed with no
further checking. In this case, rlogin does not prompt for a password,
and rcp, rdist, and rsh complete successfully. Thus, a remote user with
a local user ID is said to have ``equivalent'' access from a remote host
named in hosts.equiv. Users may expand this "equivalence" of machines by
installing a .rhosts file in their login directory. The root login
bypasses the /etc/hosts.equiv file and uses only root's (typically
/.rhosts) file.
The /etc/hosts.equiv File
The format of the hosts.equiv files consists of one or more entries of
the form:
hostname [username]
where hostname is the ``official'' fully-qualified name of a host as
listed in the hosts(4) database. The official name is the first name
given in the hosts database entry (and should include the domain name);
hostname aliases are not recognized. The domain portion of the hostname
is optional if the hostname's domain matches the one returned by
gethostname(2) or hostname(1). If a host is a gateway, i.e., it has more
than 1 network interface, then an entry for the primary name and each
gateway name may be required. The hostname can be an IP address if the
IRIS can't translate a host's IP address into a name. The username field
is optional; if missing, the name of the remote user must match the local
username. Spaces or tabs are used to separate the hostname from the
username.
The hostname field normally contains the name of a trusted host from
which a remote access can be made. However, a hostname consisting of a
single `+' indicates that all known hosts are to be trusted. (Sites
connected to external networks such as the Internet should not use `+'.)
An entry consisting of a hostname prefixed with a minus sign (-) denies
access to any user from that host. Remote access can also be given or
denied for all hosts within a specific network group (if the optional NIS
software has been enabled). An entry of the form:
+@group
means that all hosts in the named network group are trusted. An entry of
the form:
Page 1
HOSTS.EQUIV(4)HOSTS.EQUIV(4)
-@group
means that all hosts in the group are not trusted; remote access is
denied to hosts in that group, except when an entry for a specific host
appears ahead of the ``minus'' group entry.
The username field can be used to specify a user who is allowed to log in
under any valid user ID. Careful thought about security should be given
before providing this privilege to a user. You can also specify a
username field with the form:
+
-username
+@group1
-@group2
where + means any user is allowed access to any account, and -username
means the specified user is denied access (except when previous entries
allow the specific user access). The +@ netgroup allows any user in
group1 to log in as anyone, and no one from group2 to log in at all.
The User's .rhosts File
If none of the entries in /etc/hosts.equiv give access to the user's
account, the user's .rhosts file is checked if the file exists. If a
remote user is excluded by a minus entry from hosts.equiv but included in
.rhosts, then that remote user is considered trusted and given access to
the local user's account. The .rhosts file has the same format as the
hosts.equiv file. If an entry does not contain an explicit username, the
local user's name is implicitly used.
The Root .rhosts File
When the remote user attempts to a remote access to the super-user
account, root, only the /.rhosts file is checked, not /etc/hosts.equiv.
Special care should be taken in deciding the contents of root's .rhosts
file. Create root's /.rhosts only if all systems and their consoles are
physically secure and all privileged accounts have passwords. Be
selective about the systems you add to the file. Given access to a
console on a machine with /.rhosts privileges, someone can log in as any
user, including the superuser, and become root on any system that has
your system's name and root in its /.rhosts file.
NOTES
The owner of the .rhosts file must be the super-user (i.e., root) or the
user in whose home directory it resides. The contents of a user's
.rhosts file will be disregarded if it is owned by another user or if its
permissions allow anyone who is not the owner to modify the file. Use
the chmod(1) command to add the proper protection:
chmod 600 .rhosts
Page 2
HOSTS.EQUIV(4)HOSTS.EQUIV(4)
There are several caveats when default recommended permissions are not
used. The following table determine the behaviour depending on several
conditions:
__________________________________
Nfs Owner Perm. Comments
__________________________________
No user 644 yes
user 600 yes
root 644 yes
root 600 see note 1
Yes user 644 yes
user 600 yes
root 644 yes
root 600 see note 2
__________________________________
|
|
|
|
NOTES:
1. Before IRIX 6.5.22, this combination did not work. However, since
IRIX 6.5.22, this will work because .rhosts is first read as non-
root and, if it fails, root is used to read the file.
2. Same as (2) with an additional caveat that it may work if, since
this is NFS mounted, the NFS server allow root access in the exports
options.
CAUTION:
Should .rhosts be owned by root and read access denied for the user
(600 permissions), additional HOME directory protection is also
required to prevent the user to move the file around !
Likewise, /etc/hosts.equiv must be owned by and writable only by the
super-user.
If the user's home directory is NFS-mounted, the system daemons that try
to read the user's .rhosts file may fail if the NFS server treats uid 0
as ``nobody'' (see exports(4)). In this case, the permissions on the
directory and on the .rhosts file should allow read and search access by
anyone, so it may be located and read.
If rsh commands to your account on an IRIS with a .rhosts file fail with
``permission denied'' errors, for example, it means you have used the
wrong hostname or the IRIS can't translate the remote host's IP address
into a name. Rlogin to the IRIS and use the hostname or IP address
contained in the REMOTEHOST environment variable as the hostname in your
.rhosts file. The following will display the environment variable:
echo $REMOTEHOST
You must use the fully-qualified hostname of the remote system if the
IRIS's domain (as obtained from hostname(1) or gethostname(2)) is missing
or not the same as the remote domain.
Page 3
HOSTS.EQUIV(4)HOSTS.EQUIV(4)
The programs mentioned above use the ruserok(3N) library routine to grant
access based on the contents of these files. Other programs, such as
su(1M) also use this routine.
WARNING
The references to network groups (+@ and -@ entries) in hosts.equiv and
.rhosts are only supported when the netgroup file is supplied by the NIS.
Be sure to to place entries with restrictions for a host preceding
permissions for it; the effect of specifications is order-dependent.
Also, once a host is mentioned, it is no longer subject to default
action. Hence, listing it once with a specific username reference will
usually require an additional, following line which specifies the
handling for remaining users.
EXAMPLES
The following .rhosts file for user warren on host clyde.widgets.com
+
+ beatty
clyde +
bonnie.gadgets.com faye
gate-bonnie.gadgets.com faye
permits the following users on the following hosts to access warren's
account on clyde:
warren any host
beatty any host
any user clyde.widgets.com
faye bonnie.gadgets.com or gate-bonnie.gadgets.com
FILES
/etc/hosts.equiv
/etc/passwd
~/.rhosts
SEE ALSOrcp(1C), rdist(1C), rlogin(1C), rsh(1C), su(1M), rcmd(3N), ruserok(3N),
netgroup(4)
Page 4
