The hosts.equiv and .rhosts files list hosts and users that are trusted by the local host when a connection is made using the rshd service.
The hosts.equiv file resides in the ROOTDIR/etc directory and lists the remote machines that may connect to the local machine and the local user names those machines may connect as. The .rhosts file resides in a user's home directory and specifies the remote machines and remote user names that the user may use to remotely log in to the local machine.
Each line of these files has the format:
hostname may be given as a host name (typically, a fully qualified host name in a DNS environment), an address, or a + character indicating that all hosts are to be trusted.
username, if specified, may be given as either a user name on the remote host or a + character indicating all users on hostname.
When the optional username is specified, only users with entries on the specified host may log in to the local machine. When username is not specified, any user that has the same user name on both the remote and local machines may log in to the local machine.
Because the rsh and rcp utilities resend the current without the domain if it is too long and the rlogin utility does not, a user may require two entries in the hosts.equiv or .rhosts file. If the full name (including domain) is too long for the rshd service (or daemon) being used, the user needs one entry with the full user name (including domain) for use with rlogind and a second with the the same user name minus the domain for use with rshd.
Here are some examples of hosts.equiv entries for the local host machine named colossus:
- + +
Allows any user from any host to connect to colossus.
- tiny +
- big +
Allows any user from the remote hosts tiny or big to connect to colossus.
- + forbin
Allows the user forbin to connect to colossus from any remote host.
Here are some examples of .rhosts entries. In these examples, the .rhosts file is in the home directory of the user forbin on colossus.
- + +
Allows any user from any host to connect to this host (colossus) as the user forbin.
- + forbin
Allows the user forbin to connect to colossus from any remote host as the user forbin.
Also allows the user forbin to connect to colossus from any remote host as the user forbin.
- tiny mortice
Allows the user mortice from the remote host tiny to connect to colossus as the user forbin.
Here is an example of how the hosts.equiv and the .rhosts file combine. Consider a hosts.equiv file with the following entry:
and a .rhosts in the home directory of the user forbin with the following entry:
The hosts.equiv entry allows the user forbin to connect to colossus as forbin from any remote host, while the .rhosts entry allows any user from the remote host tiny to connect to colossus as forbin. When both files have entries that apply, the most restrictive combination of the entries applies. In this case, these entries combine to mean that only the user forbin from the remote host tiny can connect to colossus as forbin.
An entry of
presents two severe security hazards. First, it allows any user on any machine to connect to the local host as the same user name. Second, if it is specified in the ROOTDIR/etc/hosts.equiv file, it allows any user on any machine to connect to the local host as any user.
The user name checks provided by this mechanism are not secure, as the remote user name is received by the server unchecked for validation. Therefore, this mechanism should only be used in an environment where all hosts are completely trusted.
Specifying a numeric host address rather than a host name can somewhat help security considerations.
When a user name (or +) is specified in ROOTDIR/etc/hosts.equiv, that user (or all users, in the case of +) may log in to the local host as any local user. User names in ROOTDIR/etc/hosts.equiv should always be specified.
A .rhosts file must be owned by the user whose home directory it resides in and must be writable by only that user.
What a Windows machine thinks it is called and what UNIX systems think that Windows machine is called are often two different things. To discover what a UNIX system thinks your Windows system is called, telnet to the UNIX system and type
/bin/who am i
On many UNIX systems, this should display the name that the UNIX system knows the connected Windows machine as. If this does not work, contact the system administrator of the UNIX system for help in determining the name of your Windows machine.
This product includes software developed by the University of California, Berkeley and its contributors.
Windows Server 2012. Windows 8.1. Windows Server 2012 R2. Windows 10. Windows Server 2016. Windows Server 2019.
PTC MKS Toolkit for System Administrators
PTC MKS Toolkit for Developers
PTC MKS Toolkit for Interoperability
PTC MKS Toolkit for Professional Developers
PTC MKS Toolkit for Professional Developers 64-Bit Edition
PTC MKS Toolkit for Enterprise Developers
PTC MKS Toolkit for Enterprise Developers 64-Bit Edition
MKS Toolkit Connectivity Solutions Guide
PTC MKS Toolkit 10.3 Documentation Build 39.