|This version of this document is no longer maintained. For the latest documentation, see http://www.qnx.com/developers/docs.|
System-wide list of trusted remote hosts
The /etc/hosts.equiv and ~/.rhosts files provide the "remote authentication" database for the lpd, rcp, rlogin, and rsh commands and the rcmd() function. These files bypass the standard password-based user authentication mechanism. They specify remote hosts and users that are considered trusted (i.e. are allowed to access the local system without supplying a password):
- on a system-wide basis (/etc/hosts.equiv)
- by an individual user (~/.rhosts).
|The file permissions for the ~/.rhosts file must be as
follows or its contents will be ignored:
The ruserok() function sets the effective userid to that of the remote user, but doesn't change the effective group ID. The user must have search permissions for the directories contained in the pathname of an .rhosts file (i.e. if the file resides in /home/user/.rhosts, the user must have search permissions for /home/user/).
The library routine ruserok() (see also rcmd()) performs the remote authentication. It determines whether a particular remote user from a particular remote host is allowed to access the local system as a (possibly different) particular local user:
- For non-root users, this routine checks /etc/hosts.equiv, and then the .rhosts file in the home directory of the local user attempting access.
- For root, access is handled as a special case to help maintain system security;
only root's .rhosts file is checked.
The rlogind daemon doesn't allow root to log in without a password. When rsh is specified without command options, rlogind (not rshd) is invoked on the remote side.
If the remote authentication fails, lpd, rcp and rsh fail, but rlogin falls back to the standard password-based login procedure.
Both files are formatted as a list of one-line entries of the form:
where hostname must be the fully qualified domain name (FQDN) of the host, not one of its aliases.
The entries in these files are either positive, to explicitly allow access without a password, or negative, to deny it. Authentication succeeds as soon as a matching positive entry is found, but fails when a matching negative entry is found, or if no matching entries are found in either file. Therefore, the order of entries is important: if the files contain both matching positive and negative entries, the entry that appears first prevails.
Positive entries take these forms:
- All users from the named host are trusted and may access the system with the same user name as they have on the remote system. You can use this form in both /etc/hosts.equiv and individual users' .rhosts files.
- hostname username
- The meaning of this form depends on which file it's in:
- .rhosts file in a local user's home directory -- the named user from the named host can access the system as that local user.
- /etc/hosts.equiv -- the named remote user can access the system as any local user.
You can use the special character "+" as a wild card in place of either hostname or username to match any host or user:
- Any user from any remote host can access the system, with the same username.
- + username
- The named user from any remote host can access the system.
- hostname +
- Any user from the named host can access the system as the local user.
Negative entries have a "-" character preceding either the hostname or username field. For example:
- hostname -username
- Deny access to the named user if they attempt to access your system from the named host without providing a password.
Use extreme caution in /etc/hosts.equiv with positive entries that include a username field (either an individual named user, a netgroup, or "+" sign). Because /etc/hosts.equiv applies system-wide, these entries allow one or a group of remote users to access the system as any local user without providing a password. This can be a security hole.
The file permissions for the ~/.rhosts file must be as follows or its contents will be ignored:
- it must be owned by root or the user
- it cannot be writable by anyone other than the owner (e.g. rw-r--r-- )
rcmd() in the Library Reference