Specifies remote systems that can execute commands on the local system.
The /etc/hosts.equiv file, along with any local $HOME/.rhosts files, defines the hosts (computers on a network) and user accounts that can invoke remote commands on a local host without supplying a password. A user or host that is not required to supply a password is considered trusted.
When a local host receives a remote command request, the appropriate local daemon first checks the /etc/hosts.equiv file to determine if the request originates with a trusted user or host. For example, if the local host receives a remote login request, the rlogind daemon checks for the existence of a hosts.equiv file on the local host. If the file exists but does not define the host or user, the system checks the appropriate $HOME/.rhosts file. This file is similar to the /etc/hosts.equiv file, except that it is maintained for individual users.
Both files, hosts.equiv and .rhosts must have permissions denying write access to group and other. If either group or other have write access to a file, that file will be ignored.
Do not give write permission to the /etc/hosts.equiv file to group and others. Permissions of the /etc/hosts.equiv file should be set to 600 (read and write by owner only).
If a remote command request is made by the root user, the /etc/hosts.equiv file is ignored and only the /.rhosts file is read.
Note: Be careful when establishing trusted relationships. Networks that use trusted facilities can be less secure than those that do not.
You grant trust from a local host to a remote host or remote user. The local machine's /etc/hosts.equiv file contains entries for each trusted host or user. The format of an entry is:
The HostName field specifies the name of the host to trust. The UserName field specifies the name of the user on that remote host to trust. The UserName field is optional.
You can use the + (plus sign) as a wildcard in either the HostName or UserName field to grant trust to all users from a particular host or from all hosts that a specific user has an account on. To grant trust to every user on every machine on the network, place a plus sign (+) at the beginning of the file.
Note: When granting access through the /etc/hosts.equiv file, extreme caution must be used. Lines that include a UserName, either as an individual user, a netgroup, or the + (plus sign used as a wildcard character), permit the qualifying users to access the system as any non-root local user.
You deny a host or user trust by omitting them from the /etc/hosts.equiv file altogether. By omitting the host or user, you imply they are not trusted. This is the most secure way to deny trust. Otherwise, you can explicitly deny trust to a specific host or user by using the - (minus sign). The format to explicitly deny a host is:
The format to explicitly deny a specific user from a host is:
If your network uses the Network Information Service (NIS), you can use netgroups in place of either the HostName or UserName field. The system resolves the netgroup depending on which field the netgroup replaces. For example, if you place a netgroup in the HostName field, the system resolves the hosts component of the netgroup. If the netgroup appears in the UserName field, the user component is resolved. Use the following format to grant trust to a netgroup:
To deny trust, use the following:
Refer to the NIS netgroup file for more information on netgroups.
The order of entries in the /etc/hosts.equiv file is important. When verifying trust, the system parses the /etc/hosts.equiv file from top to bottom. When it encounters an entry that matches the host or user attempting a remote command, the system stops parsing the file and grants or denies trust based on the entry. Any additional entries that appear later in the file are ignored.
emerald amethystThese entries in diamond's /etc/hosts.equiv file allow all the users on emerald and amethyst with local accounts on diamond to remotely log in without supplying a password.
emerald amethyst gregoryThis entry in diamond's /etc/hosts.equiv file forces all the users on amethyst, except for gregory, to supply a password when remotely logging in to diamond.
emerald amethyst gregory + peterThis entry in diamond's /etc/hosts.equiv file allows peter to execute remote commands on diamond from any host that he has an account on.
emerald amethyst gregory + peter +@centuryThis entry in diamond's /etc/hosts.equiv file grants trust to all hosts in the century netgroup. This means that any user with an account on a century host and an account on diamond can execute remote commands on diamond without supplying a password.
emerald amethyst gregory + peter +@century citrine +@engineersThis entry in diamond's /etc/hosts.equiv file grants trust to all of netgroup engineers users with an account on citrine.
emerald amethyst gregory + peter +@century citrine +@engineers +@servers +@sysadminsThis entry in diamond's /etc/hosts.equiv file grants trust to any user in the sysadmins netgroup who is remotely executing commands from hosts that are in the servers netgroup.
emerald amethyst gregory + peter +@century citrine -lydia citrine +@engineers +@servers +@sysadminsThis entry in diamond's /etc/hosts.equiv file grants trust to all of netgroup engineers users, except for lydia, who must supply a password. The order of entries is very important. Recall that the system grants trust based on the first entry it encounters. If the order of the entries appeared as follows:
emerald amethyst gregory + peter +@century citrine +@engineers citrine -lydia +@servers +@sysadminsUser lydia, as a member of engineers, would be allowed to execute remote commands on diamond even though a later entry explicitly denies her trust.
This file is part of TCP/IP in Network Support Facilities in Base Operating System (BOS) Runtime.
|$HOME/.rhosts||Specifies remote users who can use a local-user account.|
The NIS netgroup file.
The TCP/IP .rhosts file format.
The lpd command, rcp command, rdist command, rdump command, rlogin command, rsh command, ruser command.
The rlogind daemon, rshd daemon.
Naming in AIX Version 4.3 System Management Guide: Communications and Networks.