Next: , Previous: , Up: Top   [Contents][Index]

22 rlogind: Remote login server

rlogind is the server for the rlogin client program (see rlogin invocation). The server provides a remote login facility with authentication based on privileged port numbers from trusted hosts, or using authentication according to a Kerberos protocol.

rlogind in daemon mode listens for service requests at the port indicated in the ‘login’ service specification. A common alternative is to have the super-server inetd listen at the same port, which then invokes rlogind as demand arises. In Kerberised mode, the port is either ‘eklogin’, or ‘klogin’, depending on preset encryption, or none.

The standard authentication procedure assumes the integrity of each client machine and of the connecting medium. This is insecure, since it transmits credentials in clear text, but is useful in an “open” environment. This weakness is reduced when running the service in Kerberised version, at the price of a larger complexity of the supporting infrastructure. Using an encrypting Kerberised service even avoids all clear text processing.

22.1 Invoking

The available options are as follows:


Accept only IPv4 connections in daemon mode.


Only IPv6 connections in daemon mode.


Ask hostname for verification.


Run in background daemon mode, optionally setting the maximal number of simultaneously running client sessions. The default limit is 10.


Set debug level, not implemented.


Ignore client’s .rhosts file.

-L name

Set local domain name, to which the server host belongs. By default the domain is recovered from the canonical name of the host.


Do not set SO_KEEPALIVE on sockets. This decreases the ability to close lost connections to once active clients.


Allow the root user to login, which is disallowed by default.

-p port

Listen on given port. Applicable only in daemon mode.


Require reverse resolvability of remote host’s numerical IP.

For sites requiring improved authentication, Kerberos authentication is a viable decision, and possibly even with encryption for enhanced integrity. Three additional options are available for an executable rlogind compiled with Kerberos support.


Activate Kerberos authentication on all incoming requests.

-S name

Set Kerberos server name, overriding canonical hostname.


Activate encryption of all data passed via the rlogind session. This may impact response time and CPU utilization, but provides increased security. Only for Kerberised mode of operation.

Should rlogind have been built with PAM support, it reads any setting specified for a service named either ‘rlogin’ or ‘krlogin’, the latter name for clients using Kerberised authentication.

22.2 Kerberos specific details

The option -k is mandatory for Kerberised operation mode, while addition of the option -x will also demand encryption of every request to this particular server.

rlogind will, in Kerberised operation mode, as default instantiate itself using the principal name ‘host/canonical_name@DEFAULT_REALM’, a compound arranged from the running host’s canonical name, and from the default realm configured for the system. Either of these can be overridden using the option --server-principal, as follows:

rlogind -k -S alias.server.our
rlogind --kerberos --server-principal=@NEW.REALM
rlogind -k -x -S rlogin/

When overriding only the realm, with the option -S, an initial at-sign is mandatory.

22.3 Protocol details

When a service request is received, in non-Kerberised mode, the following protocol is initiated:

  1. The server checks the client’s source port. If the port is not in the range 512-1023, the server aborts the connection.
  2. The server next checks the client’s source address and requests the corresponding host name. If the hostname cannot be determined, the numerical representation of the host address is used. If the hostname is in the same domain as the server (according to the last two components of the domain name), or if the option -a is in effect, the address for the hostname is requested, verifying that the name and address correspond. Normal authentication is considered as failed, should this address verification fail.

Once the source port and address have been checked, rlogind proceeds with the authentication process as described in rshd invocation. The server then allocates a pseudo terminal, and manipulates file descriptors so that the slave half of the pseudo terminal becomes the stdin, stdout, and stderr for a login process. The login process is an instance of the login program, invoked with the option -f if authentication had succeeded. If automatic authentication had failed, the user is prompted to log in as if on a standard terminal line.

The parent of the login 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. In normal operation, the packet protocol described in ‘PTY’ is invoked to provide flow control using C-S/C-Q, and to propagate interrupt signals to the remote program. The login process transmits the client terminal’s baud rate, and its terminal type, as found in the environment variable TERM. The screen or window size of the terminal is requested from the client, and any later window size changes at the client’s side are propagated to the pseudo terminal as well.

Transport-level keepalive messages are enabled unless the option -n was in effect when starting rlogind. The use of keepalive messages allows sessions to be timed out, should the client crash, or otherwise become unreachable.

See ruserok in The GNU C Library Reference Manual, for details.

22.4 Diagnostics

The exchange protocol states that a negotiation reaches a successful completion as soon as the server rlogind transmits back to the client a single null byte, marking the completion of all information exchange.

Error conditions are instead transmitted back to the client as a message containing an initial byte value 1, followed by a C-string indicating the cause of failure. All network connections are closed at the server side after this message. Some common messages follow:

Permission denied.

The client presented insufficient credentials, or the client’s address is not sufficiently resolvable to pass the checks induced by options -a or -r.

Try again.

A fork by the server failed.

Next: , Previous: , Up: Top   [Contents][Index]