*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> hosts.equiv (4)              



NAME    [Toc]    [Back]

     hosts.equiv, rhosts - trusted hosts by system and by user

DESCRIPTION    [Toc]    [Back]

     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

     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:


     means that	all hosts in the named network group are trusted.  An entry of
     the form:

									Page 1



     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:


     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    [Toc]    [Back]
     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    [Toc]    [Back]

     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

     Likewise, /etc/hosts.equiv	must be	owned by and writable only by the

									Page 2


     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:


     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.

     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    [Toc]    [Back]

     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    [Toc]    [Back]

     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

									Page 3


FILES    [Toc]    [Back]


SEE ALSO    [Toc]    [Back]

     rcp(1C), rdist(1C), rlogin(1C), rsh(1C), su(1M), rcmd(3N),	ruserok(3N),

									PPPPaaaaggggeeee 4444
[ Back ]
 Similar pages
Name OS Title
hosts.equiv OpenBSD trusted remote hosts and host-user pairs
hosts.equiv Linux list of hosts and users that are granted "trusted" r command access to your system
hosts.lpd FreeBSD trusted hosts that may use local print services
hosts.equiv FreeBSD trusted remote host and user name data base
rhosts FreeBSD trusted remote host and user name data base
getprdfent HP-UX manipulate system default database entry for a trusted system
setprdfent HP-UX manipulate system default database entry for a trusted system
endprdfent HP-UX manipulate system default database entry for a trusted system
getprdfnam HP-UX manipulate system default database entry for a trusted system
putprdfnam HP-UX manipulate system default database entry for a trusted system
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service