rlogind(1M)

NAME

rlogind — remote login server

SYNOPSIS

/usr/lbin/rlogind [-ln] [-B bannerfile]

Kerberos V5 Network Authentication environments:

/usr/lbin/rlogind [-clnKkRr] [-B bannerfile]

DESCRIPTION

rlogind is the server for the rlogin(1) program. It provides a remote login facility with two kinds of authentication methods:

1.: Authentication based on privileged port numbers where the client's source port must be in the range 512 through 1023. In this case rlogind assumes it is operating in normal or non-secure environment.
2.: Authentication based on Kerberos V5. In this case rlogind assumes it is operating in a Kerberos V5 Network Authentication, i.e., secure environment.

The inetd daemon invokes rlogind if a service request is received at ports indicated by the login or klogin services specified in /etc/services (see inetd(1M) and services(4)). Service requests arriving at the klogin port assume a secure environment and expect Kerberos authentication to take place.

To start rlogind from the inetd daemon in a non-secure environment, the configuration file /etc/inetd.conf must contain an entry as follows:

login  stream  tcp  nowait  root  /usr/lbin/rlogind  rlogind 

In a secure environment, /etc/inetd.conf must contain an entry:

klogin  stream  tcp  nowait  root  /usr/lbin/rlogind  rlogind -K 

See inetd.conf(4) for more information.

To prevent non-secure access, the entry for login should be commented out in /etc/inetd.conf. Any non-Kerberos access will be denied since the entry for the port indicated by login has now been removed or commented out. In a such a situation, a generic error message,

rcmd: connect <hostname> : Connection refused 

is displayed. See DIAGNOSTICS for more details.

Options

rlogind recognizes the following options:

-c: Ignore checksum verification. This option is used to achieve interoperability between clients and servers using different checksum calculation methods. For example, the checksum calculation in a application developed with Kerberos V5 Beta 4 API is different from the calculation in a Kerberos V5-1.0 application.
-l: Prevents any authentication based on the user's .rhosts file unless the user is logging in as super-user.
-Bbannerfile: Causes the file, bannerfile, to be displayed to incoming rlogin requests.

In a secure environment, rlogind will recognize the following additional options:

-K

Authorization based on Kerberos V5 must succeed or access will be rejected (see sis(5) for details on authorization).

-R

Authentication based on privileged port numbers and authorization of the remote user through equivalent accounts must succeed. For more information on equivalent accounts, see hosts.equiv(4).

-r

Either one of the following must succeed. The order in which the authorization checks are done is as specified below.

1.: Authentication based on privileged port numbers and authorization of the remote user through equivalent accounts (see hosts.equiv(4)).
2.: Authorization based on Kerberos V5.

-k

Either one of the following must succeed. The order in which the authorization checks are done is as specified below.

1.: Authorization based on Kerberos V5.
2.: Authentication based on privileged port numbers and authorization of the remote user through equivalent accounts.

Note: The -k option is ignored when used with -K, and the -r option is ignored when used with -R. Also, if no options are specified, the default option is -K.

Operation

When a service request is received, the following protocol is initiated by rlogind:

1.

rlogind checks the client's source port. If the port is not in a privileged port, i.e., in the range 512 through 1023, and rlogind is operating in a non-secure environment, the connection is terminated. In a secure environment, the action taken depends on the command line options:

-R: The source port must be a privileged port otherwise rlogind terminates the connection.
-r: If the source port is not a privileged port then Kerberos authorization must succeed or the connection is terminated.
-k: The source port must be a privileged port if Kerberos authorization fails.
-K: No action is taken.

2.

rlogind checks the client's source address and requests the corresponding host name (see gethostent(3N), hosts(4), and named(1M)). If it cannot determine the hostname, it uses the Internet dot-notation representation of the host address.

3.

rlogind, in a secure environment, proceeds with the Kerberos authentication process described in sis(5). If authentication succeeds, then the authorization selected by the command line option -K, -R, -k, or -r is performed. The authorization selected could be as specified in hosts.equiv(4) or Kerberos authorization as specified in sis(5).

4.

rlogind then allocates a STREAMS based pseudo-terminal (see ptm(7), pts(7)), and manipulates file descriptors so that the slave half of the pseudo-terminal becomes stdin, stdout, and stderr for a login process.

5.

This login process is an instance of login(1) invoked with the -f option if authentication has succeeded. In a non-secure environment, if automatic authentication fails, login(1) prompts the user with the normal login sequence. In a secure environment, if authentication fails, rlogind generates an error message and quits.

The rlogind process manipulates the master side of the pseudo-terminal, operating as an intermediary between the login process and the client instance of the rlogin program. The protocol described in ptm(7) and pts(7) is used to enable and disable flow control via Ctrl-S/Ctrl-Q under the direction of the program running on the slave side of the pseudo-terminal, and to flush terminal output in response to interrupt signals. The login process sets the baud rate and TERM environment variable to correspond to the client's baud rate and terminal type (see environ(5)).

Transport-level keepalive messages are enabled unless the -n option is present. The use of keepalive messages allows sessions to be timed out if the client crashes or becomes unreachable.

EXTERNAL INFLUENCES

International Code Set Support

Single- and multibyte character code sets are supported.

DIAGNOSTICS

Errors in establishing a connection cause an error message to be returned with a leading byte of 1 through the socket connection, after which the network connection is closed. Any errors generated by the login process or its descendents are passed through by the server as normal communication.

fork: No more processes

The server was unable to fork a process to handle the incoming connection.

Next step: Wait a period of time and try again. If this message persists, the server's host may have runaway processes that are using all the entries in the process table.

Cannot allocate pty on remote host

The server was unable to obtain a pseudo-terminal for use with the login process. Either all pseudo-terminals were in use, or the pty driver has not been properly set up. Note, the number of slave devices that can be allocated depends on NSTRPTY, a kernel tunable parameter. This can be changed via SAM ( see ptm(7), pts(7)).

Next step: Check the pty configuration of the host where rlogind executes.

Permission denied

The server denied access because the client was not using a reserved port. This should only happen to interlopers trying to break into the system.

/usr/bin/login: ...

The login program could not be started via exec(2) for the reason indicated.

Next step: Try to correct the condition causing the problem. If this message persists, contact your system administrator.

rcmd: connect : <hostname>: Connection refused.

This generic message could be due to a number of reasons. One of the reasons could be because the entry for login service is not present in /etc/inetd.conf. This entry may have been removed or commented out to prevent non-secure access.

Kerberos specific errors are listed in sis(5).

WARNINGS

The integrity of each host and the connecting medium is assumed if the "privileged port" authentication procedure is used in a non-secure environment or if the command line options -R or -r are used in a secure environment. Although both these methods provide insecure access, they are useful in an "open" environment. This is insecure, but is useful in an ``open'' environment.

Note also that all information, including any passwords, are passed unencrypted between the two hosts when rlogind is invoked in a non-secure environment.

AUTHOR

rlogind was developed by the University of California, Berkeley.

FILES

/etc/hosts.equiv: List of equivalent hosts
$HOME/.rhosts: User's private equivalence list