Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

hosts.equiv(5) [ultrix man page]

hosts.equiv(5)							File Formats Manual						    hosts.equiv(5)

Name
       hosts.equiv - list of trusted hosts

Description
       The file resides in the directory and contains a list of trusted hosts.	When an or request from a host listed in the file is made, and the
       initiator of the request has an entry in further validity checking is not required.  Thus, does not prompt for a  password,  and  completes
       successfully.  When a remote user is in the local file, that user is defined as equivalenced to a local user with the same user ID.

       The format of is a list of names, as in:
       host1
       -host2
       +@group1
       -@group2

       A  line	consisting  of a host name means that anyone logging in from that host is trusted.  A line consisting of a host name preceded by -
       means that anyone logging in from that host is not trusted.  A line consisting of a single + means that all hosts are trusted.	Placing  a
       line consisting of a single + in your file poses substantial security risks and is not recommended.

       The  +@ and -@ syntax are specific to Yellow Pages (YP).  A line consisting of +@group means that all hosts in that network group (which is
       served by YP) are trusted.  A line consisting of -@group means that hosts in that network group (which is served by YP)	are  not  trusted.
       Programs  scan  the  file sequentially and stop when they encounter the appropriate entry (either positive for host name and +@ entries, or
       negative for -@ entries).

       The file has the same format as the file.  When a user executes or the file from that user's home directory is concatenated onto  the  file
       for  permission	checking.  The host names listed in the and files may optionally contain the local BIND domain name.  For more information
       on BIND, see the Guide to the BIND/Hesiod Service.  If a user is excluded by a minus entry from but included in	that  user  is	considered
       trusted.  In the special case when the user is root, only the file is checked.

       It  is  possible to have two entries on a single line.  Separate the entires with a space.  If the remote host is equivalenced by the first
       entry, the user named by the second entry is allowed to specify any name to the option (provided that name is in the file).  For example:
       suez john
       This entry allows John to log in from suez.  The normal use would be to put this entry in the file in the home directory for  bill.   Then,
       John can log in as bill when coming from suez without having to supply a password.  The second entry can be a netgroup.	For example:
       +@group1 +@group2
       This entry allows any user in group2 coming from a host in group1 to log in as anyone.

Files
       /var/yp/domain/netgroup
       /var/yp/domain/netgroup.byuser
       /var/yp/domain/netgroup.byhost

See Also
       rlogin(1c), rsh(1c), netgroup(5yp)
       Guide to the BIND/Hesiod Service
       Guide to the Yellow Pages Service

																    hosts.equiv(5)

Check Out this Related Man Page

HOSTS.EQUIV(5)						      BSD File Formats Manual						    HOSTS.EQUIV(5)

NAME
hosts.equiv, .rhosts -- trusted remote hosts and host-user pairs DESCRIPTION
The hosts.equiv and .rhosts files list hosts and users which are ``trusted'' by the local host when a connection is made via rlogind(8), rshd(8), or any other server that uses ruserok(3). This mechanism bypasses password checks, and is required for access via rsh(1). Each line of these files has the format: hostname [username] The hostname may be specified as a host name (typically a fully qualified host name in a DNS environment) or address, +@netgroup (from which only the host names are checked), or a ``+'' wildcard (allow all hosts). The username, if specified, may be given as a user name on the remote host, +@netgroup (from which only the user names are checked), or a ``+'' wildcard (allow all remote users). If a username is specified, only that user from the specified host may login to the local machine. If a username is not specified, any user may login with the same user name. EXAMPLES
somehost A common usage: users on somehost may login to the local host as the same user name. somehost username The user username on somehost may login to the local host. If specified in /etc/hosts.equiv, the user may login with only the same user name. +@anetgroup username The user username may login to the local host from any machine listed in the netgroup anetgroup. + + + Two severe security hazards. In the first case, allows a user on any machine to login to the local host as the same user name. In the second case, allows any user on any machine to login to the local host (as any user, if in /etc/hosts.equiv). WARNINGS
The username checks provided by this mechanism are not secure, as the remote user name is received by the server unchecked for validity. Therefore this mechanism should only be used in an environment where all hosts are completely trusted. A numeric host address instead of a host name can help security considerations somewhat; the address is then used directly by iruserok(3). When a username (or netgroup, or +) is specified in /etc/hosts.equiv, that user (or group of users, or all users, respectively) may login to the local host as any local user. Usernames in /etc/hosts.equiv should therefore be used with extreme caution, or not at all. A .rhosts file must be owned by the user whose home directory it resides in, and must be writable only by that user. Logins as root only check root's .rhosts file; the /etc/hosts.equiv file is not checked for security. Access permitted through root's .rhosts file is typically only for rsh(1), as root must still login on the console for an interactive login such as rlogin(1). FILES
/etc/hosts.equiv Global trusted host-user pairs list ~/.rhosts Per-user trusted host-user pairs list SEE ALSO
rcp(1), rlogin(1), rsh(1), rcmd(3), ruserok(3), netgroup(5) HISTORY
The .rhosts file format appeared in 4.2BSD. BUGS
The ruserok(3) implementation currently skips negative entries (preceded with a ``-'' sign) and does not treat them as ``short-circuit'' neg- ative entries. BSD
November 26, 1997 BSD
Man Page