Authentication for Remote Logins (rlogin)

Authentication (establishing who you are) for rlogin operations can be performed either by the remote system or by the network environment.

The main difference between these forms of authentication lies in the type of interaction they require from you and the way they are established. If a remote system tries to authenticate you, you are prompted for a password, unless you set up the /etc/hosts.equiv or .rhosts file. If the network tries to authenticate you, you are not asked for a password, because the network already knows who you are.

When the remote system attempts to authenticate you, it relies on information in its local files, specifically if one of the following is true:

• Your system name and user name appear in the remote system's /etc/hosts.equiv file.

• Your system name and user name appear in the remote user's .rhosts file, under the remote user's home directory.

Network authentication relies on one of these two methods:

• A “trusting network environment” that has been set up with your local network information service and the automounter.

• One of the network information services that is pointed to by the remote system's /etc/nsswitch.conf file contains information about you.

Network authentication generally supersedes system authentication.

/etc/hosts.equiv File

The /etc/hosts.equiv file contains a list of trusted hosts for a remote system, one per line. If a user attempts to log in remotely (using rlogin) from one of the hosts that is listed in this file, and if the remote system can access the user's password entry, the remote system allows the user to log in without a password.

A typical hosts.equiv file has the following structure:

host1
host2 user_a
+@group1
-@group2

When a simple entry for a host is made in hosts.equiv, such as the previous entry for host1, it means that the host is trusted, and so is any user at that machine.

If the user name is also mentioned, as in the second entry in the example, then the host is trusted only if the specified user is attempting access.

A group name that is preceded by a plus sign (+) means that all the machines in that netgroup are considered trusted.

A group name that is preceded by a minus sign (–) means that none of the machines in that netgroup is considered trusted.

Security Risks When Using the /etc/hosts.equiv File

The /etc/hosts.equiv file presents a security risk. If you maintain a /etc/hosts.equiv file on your system, you should include only trusted hosts in your network. The file should not include any host that belongs to a different network, or any machines that are in public areas. For example, do not include a host that is located in a terminal room.

The use of hosts that are not trusted can create a serious security problem. Either replace the /etc/hosts.equiv file with a correctly configured one, or remove the file altogether.

A single line of + in the /etc/hosts.equiv file indicates that every known host is trusted.

.rhosts File

The .rhosts file is the user equivalent of the /etc/hosts.equiv file. This file contains a list of host-user combinations, rather than hosts in general. If a host-user combination is listed in this file, the specified user is granted permission to log in remotely from the specified host without having to supply a password.

Note that a .rhosts file must reside at the top level of a user's home directory. .rhost files that are located in subdirectories are not consulted.

Users can create .rhosts files in their home directories. Using the .rhosts file is another way to allow trusted access between users' own accounts on different systems without using the /etc/hosts.equiv file.

Security Risks When Using the .rhosts File

Unfortunately, the .rhosts file presents a major security problem. While the /etc/hosts.equiv file is under the system administrator's control and can be managed effectively, any user can create a .rhosts file that grants access to whomever the user chooses without the system administrator's knowledge.

In a situation in which all of the users' home directories are on a single server and only certain people have superuser access on that server, a good way to prevent a user from using a .rhosts file is to create an empty file as superuser in their home directory. You would then change the permissions in this file to 000 so that it would be difficult to change it, even as superuser. This change would effectively prevent a user from risking system security by using a .rhosts file irresponsibly. The change would not, however, solve anything if the user is able to change the effective path to his or her home directory.

The only secure way to manage .rhosts files is to completely disallow them. See How to Search for and Remove .rhosts Files for detailed instructions. As system administrator, you can check the system often for violations of this policy. One possible exception to this policy is for the root account; you might need to have a .rhosts file to perform network backups and other remote services.