The rlogin program is one of several r-commands. These commands were developed to provide various types of remote access to a UNIX system (hence the name ; rlogin is short for remote login ). When you run the rlogin client, it attempts to connect to a server that's called rlogind or in.rlogind . One of the merits of rlogind is that it's easy to configure; it has few options, so you don't need to deal with complex configuration files. Unfortunately, the protocol is also very primitive by today's security standards. Although it's easy to use, controlling access to a system that uses rlogind can be tricky.
Setting rlogind Startup Options
The rlogind server is usually launched from a super server, as described in Chapter 4, Starting Servers. Most distributions that use inetd include an entry for rlogind in their /etc/inetd.conf files, although that entry is often commented out by default. To run the server, you need only uncomment the line and restart the super server. Distributions that use xinetd generally provide a startup file in /etc/xinetd.d to start the server. This file is often configured to disable the server by default, so you may need to edit it to enable the server, as described in Chapter 4.
The rlogind server accepts a handful of parameters that influence its behavior. These are:
Understanding rlogind Security
All of the r-commands use a security model that's generally considered by today's standards to be quaint at best, and hopelessly insecure at worst. In part, this is because the protocol is built on a trusted hosts security model, in which the server trusts the client with much of the authentication task. There are ways to tighten rlogind 's security to a limited extent, though, and using a Kerberos-enabled version of the program can help even more. When a user attempts to connect to an rlogind server, the system takes the following steps to authenticate the user:
Several of the preceding steps rely upon rlogind knowing the connecting user's username. This information is passed quietly from one system to another, or you can specify the username with the rlogin client's -l parameter, as in rlogin -l sjones .
Because rlogind uses a trusted hosts security model, and because the hosts it trusts can be configured by individual users via their .rhosts files, the server's security may be circumvented in several different ways. These include compromising the security of the client, spoofing a trusted client's IP address, removing a trusted client from the network and replacing it with one that the attacker controls, and replacing or adding to the .rhosts file in the target user's account. Many of these modes of attack aren't trivially easy, particularly on a network with otherwise strong security, but the combination makes rlogind a poor choice of remote login protocol in most situations. It does have one advantage, though: Under many circumstances, rlogind doesn't require the user to enter either a username or a password, so access to the server system is quick and easy:
[rodsmith@nessus rodsmith]$ rlogin speaker Last login: Mon Aug 12 14:48:58 2002 from nessus on 4 [rodsmith@speaker rodsmith]$
Another characteristic of rlogind is that it uses unencrypted data transfers. These are discussed in more detail in the upcoming section, "Understanding Telnet Security." The bottom line is that your data may be intercepted, so you should use rlogind only on small private networks that you're confident have not been compromised.
In sum, if a scripted login or otherwise quick access is required, rlogind may be worth considering, but its weak security model means you should be wary of it in most circumstances. The Telnet protocol requires use of passwords in most situations, and SSH is even more secure.
Controlling rlogind Access
If you do choose to use rlogind , the server prompts for a password when a login is attempted from an untrusted host. Chances are, though, that you want to use rlogind because it doesn't require the use of a username or password, so you want to configure it to trust certain hosts. This may be done in two ways:
Both these files control access to all r-command serversprincipally rlogin , rcp , and rsh . When the computer uses the BSD LPD printing system (described in Chapter 9, Printer Sharing via LPD), these files also control access to that system. (As described in Chapter 9, a printer-specific configuration file may be used instead of these general-purpose r-command control files.)
Both these files have the same format, although the interpretation of some elements differs slightly from one file to the other. The file consists of a series of lines that describe individual hosts or groups of hosts. Each line's format is specified as follows :
[+-][ hostname ] [ username ]
The leading plus ( + ) or minus ( - ) sign explicitly allows or denies access from the specified client. The default is to allow the host, so the plus sign may be omitted in most cases. The minus sign, by contrast, may be used to explicitly deny a client access when it would otherwise be allowed by a preceding line that specifies several hosts, as described shortly.
You may specify the hostname as either an IP address (such as 192.168.34.56 ) or as a hostname (such as gingko.threeroomco.com ). In the latter case, the hostname may be either a fully qualified domain name (FQDN), such as the full gingko.threeroomco.com , or a machine name alone if the two computers are in the same domain, such as gingko if the server is in the same domain as gingko . If you precede a name with an at-sign ( @ ), it refers to an NIS domain (your system must be configured to use NIS for this form to work). The safest form in which to specify hosts is as IP addresses, followed by FQDNs, followed by machine names only.
If you include a username in the list, this gives the listed user full access to the system. In the case of the .rhosts file, this means that the listed user is equivalent to the user in whose directory the .rhosts file resides. For instance, suppose julia includes the following line in her .rhosts file:
This configuration grants the user jbrown on 172.21.13.14 access to julia 's account on the server using rlogin , and similar privileges using rsh and rcp . (From the jbrown account on the client, the user will have to use the -l julia option to rlogin to log in to julia 's account on the server.)
The phrase "full access to the system" has a stronger meaning in the case of /etc/hosts.equiv . When a username appears in this file, the effect is that the named user of the remote system has unfettered access to all accounts on the server, with the exception of root . Thus, if the preceding example line was added to /etc/hosts.equiv , jbrown on 172.21.13.14 could use rlogin to gain access not just to the julia account, but to any other ordinary user's account. In this context, "ordinary user" includes system accounts like daemon , which can often be abused to acquire root privileges. Thus, specifying a username isn't safe in /etc/hosts.equiv , except possibly in explicit denial situations (when the line begins with a minus sign).
In addition to the access controls provided by ~/.rhosts , /etc/ hosts.equiv , and passwords in case these files don't give automatic access to a client, you can use other control mechanisms to restrict access to an rlogind server. Because this server is usually run from inetd or xinetd , you can use TCP Wrappers or xinetd 's access control features to limit access to specific IP addresses or by other means. I strongly recommend you do so. A packet filter firewall rule can also block access to the rlogin port (TCP port 513), as described in Chapter 25, Configuring iptables.