NOTE. Starting with the Solaris 9 release, Secure Shell is recommended for secure remote login. See "Secure Shell Commands" on page 359 for more information.

Authentication for Remote Logins (rlogin)

The remote system or the network environment can perform authentication to establish who the user is for rlogin operations.

The main differences between these forms of authentication are in the type of interaction they require from the user and the way the authentication is established. If a remote system tries to authenticate a user, the user is prompted for a password unless the user is included in the /etc/hosts.equiv or .rhosts file on the remote system. If the network authenticates the user, no password is required because the network already knows who the user is.

Network authentication relies on either a trusting network environment set up with your local nameservice and the automounter or one of the nameservices pointed to by the remote system's /etc/nsswitch.conf file.

NOTE. Network authentication usually supersedes system authentication.

The rlogin command also interacts with the Pluggable Authentication Module (PAM) subsystem for authentication and may require configuration of the /etc/pam.conf file for authentication to work. For complete information on PAM, refer to the Sun System Administration Guide: Security Services or the "Using Authentication Services" chapter in the Solaris Advanced System Administrator's Guide available from Sun Microsystems Press and Prentice Hall.

Remote System Authentication

When the remote system tries to authenticate a user, it relies on information in its local /etc/hosts.equiv or .rhosts files. If the user's system or host name is included in the remote system's /etc/hosts.equiv file, authentication is automatic and the user can use the rlogin command without typing a password. Alternatively, authentication is automatic with the rlogin command when the user has a remote home directory with a .rhosts file that includes the user's system name and user name.

The /etc/hosts.equiv File

The /etc/hosts.equiv file contains a list of trusted hosts for a remote system, one entry per line. If a user tries to log in remotely with the rlogin command from one of the hosts listed in this file, and if the remote system can access the password entry for the user, the remote system enables the user to log in without a password.

When the /etc/hosts.equiv file contains an entry consisting of just a host name, such as the host1 entry above, the host is trusted and so is any user at that system.

If the user name is also mentioned, as in the second entry above, then the host is trusted only for that specified user.

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

A netgroup name preceded by a minus sign (-) means that none of the systems in that netgroup are considered trusted.

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

The /etc/hosts.equiv file presents a security risk, especially if it contains a + entry. If you maintain an /etc/hosts.equiv file on a system, include only trusted hosts in your network. Do not include any host that belongs to a different network or any systems that are in public areas. For example, do not include a host for which you do not have administrative control.

The .rhosts File

The .rhosts file is the user equivalent of the /etc/hosts.equiv file. It contains a list of host-user combinations instead of 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. A .rhosts file must reside at the top level of a user's home directory. .rhosts files located in subdirectories are not consulted.

Users can create .rhosts files in their home directories. Using the .rhosts file is another way to enable trusted access between an individual's user accounts on different systems without using the /etc/hosts.equiv file.

Unfortunately, the .rhosts file presents a major security problem. While the /etc/hosts.equiv file is under the control of system administrators and can be managed effectively, any user can create a .rhosts file granting access to whomever the user chooses without the system administrator's knowledge. The only secure way to manage .rhosts files is to completely disallow them.

The following example removes all .rhosts files in the users' home directories located in the /export/home directory.

Network Authentication

Network information is stored in NIS maps, NIS+ tables, or LDAP. Network authentication relies on one of the following two methods.

What Happens After You Log In Remotely

When you log in to a remote system, the in.rlogind daemon tries to find your home directory. If the in.rlogind daemon can't find your home directory, it assigns you to the root (/) directory on the remote system and the following message is displayed.

When you invoke the rlogin command on your local host, inetd(1M) on the remote host invokes the in.rlogind daemon. The server checks the client's source port. If the port is not in the range 512–1023, the server aborts the connection. The server checks the client's source address. If an entry for the client exists in both /etc/inet/hosts and /etc/hosts.equiv, a user logging in from the client is not prompted for a password. If the address is associated with a host for which no corresponding entry exists in /etc/inet/hosts or if the host name is found in the NIS or NIS+ hosts map or in DNS, the user is prompted for a password, regardless of whether an entry for the client is present in /etc/hosts.equiv.

Once the source port and address are checked, in.rlogind allocates a pseudoterminal and manipulates file descriptors so that the slave half of the pseudoterminal becomes the standard input, standard output, and standard error for a login process.

The login process is an instance of the login(1) program invoked with the -r option. The login process then proceeds with the pam (3PAM) authentication process. If the login program finds your home directory, it sources both the .cshrc and .login files for the C shell or the .profile file for the Bourne shell. Therefore, your prompt on the remote system is your standard login prompt, and the current directory is the same as for a local login. For example, if your usual prompt is your system name followed by the percent (%) sign, such as paperbark%, when you log in to a remote system, the remote system name is displayed as the login prompt.