RFC 1282

BSD Rlogin 💖

• RFC 1282: BSD Rlogin 🎀
• Author: Brian Kantor, Univ. of Calif San Diego 🧚
• Series: Network Working Group 🌸
• Date: December 1991 📅
• Obsoletes: RFC 1258 💅
• Status: informational, not an Internet standard 🫶

Status of This Memo ✨

Okay so this memo documents an existing protocol and common implementation that is extensively used on the Internet. It gives info to the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. 🌸

Protocol Description 🎀

The rlogin facility gives you a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output [1]. It's super popular between Unix hosts because it carries more of the Unix terminal environment semantics than the Telnet protocol does. On lots of Unix hosts it can also be set up to skip password entry when connections come from trusted hosts. 💅

The rlogin protocol requires the use of TCP. The contact port is 513. An eight-bit transparent stream is assumed. 🦋

Connection Establishment ✨

Upon connection establishment, the client sends four null-terminated strings to the server. The first is an empty string (so it's just a single zero byte). After that come three non-null strings: the client username, the server username, and the terminal type and speed. Here's the breakdown:

<null>
client-user-name<null>
server-user-name<null>
terminal-type/speed<null>

For example:

<null>
bostic<null>
kbostic<null>
vt100/9600<null>

The server returns a zero byte to say it got these strings and is now in data transfer mode. Window size negotiation may follow this initial exchange (see below). 🧚

From Client to Server (and Flow Control) 🔥

Initially, the client starts in "cooked" (as opposed to "raw") mode. In this mode, the START and STOP characters (usually ASCII DC1,DC3) get intercepted and interpreted by the client to start and stop output from the remote server to the local terminal. Every other character gets sent to the remote host as it's received. (But see below for the handling of the local-escape character. 👀)

In "raw" mode, START and STOP aren't processed locally. They get sent like any other character to the remote server. So the server decides what they mean in raw mode. They may be used for flow control, or they may have totally different meanings from their usual job on the client. 💜

Screen/Window Size 🦋

The remote server tells the client it can accept window size change info by requesting a window size message (as out of band data) right after connection establishment and the user identification exchange. The client should reply to this request with the current window size.

If the remote server has said it can accept client window size changes, and the client's window or screen dimensions change, a 12-byte special sequence is sent to the remote server. It shows the current dimensions of the client's window, in case the user process running on the server cares to use that info. 🌈

The window change control sequence is 12 bytes long. It starts with a magic cookie (two consecutive bytes of hex FF), followed by two bytes containing lower-case ASCII "s". Then come 8 bytes containing the 16-bit values for the number of character rows, the number of characters per row, the number of pixels in the X direction, and the number of pixels in the Y direction, all in network byte order. So it looks like this:

FF FF s s rr cc xp yp

Other flags than "ss" may be used in future for other in-band control messages. None are currently defined. ⭐

From Server to Client 💜

Data from the remote server gets sent to the client as a stream of characters. Normal data just goes to the client's display, but it may get processed before it's displayed (tabs expanded, etc.). 🍓

The server can embed single-byte control messages in the data stream. It does this by inserting the control byte into the stream and pointing the TCP "urgent-data" pointer at that control byte. When the client gets a TCP urgent-data pointer, the data in the TCP stream up to the urgent byte is buffered for possible display after the control byte is handled. The control byte it points to is received and interpreted as follows:

• 02: A control byte of hex 02 causes the client to discard all buffered data received from the server that has not yet been written to the client user's screen. 🗑️
• 10: A control byte of hex 10 commands the client to switch to "raw" mode, where the START and STOP characters are no longer handled by the client, but are treated as plain data. 🧃
• 20: A control byte of hex 20 commands the client to resume interception and local processing of START and STOP flow control characters. ▶️
• 80: The client responds by sending the current window size as above. 📐

All other values of the urgent-data control byte are ignored. In all cases, the byte pointed to by the urgent data pointer is not written to the client user's display. 🙈

Connection Closure 🌈

When the TCP connection closes in either direction, the client or server process that notices the close should perform an orderly shut-down. That means restoring terminal modes and notifying the user or processes of the close before it closes the connection in the other direction. 🫧

Implementation Notes 🍓

The client defines a client-escape character (customarily the tilde, "~"). It's handled specially only if it's the first character typed at the beginning of a line. (The beginning of a line is defined as the first character typed by the client user after a new-line [CR or LF] character, after a line-cancel character, after resumption of a suspended client session, or after initiation of the connection.) 🧁

The client-escape character isn't transmitted to the server until the character after it has been examined. If that character is one of the defined client escape sequences, neither the client-escape nor the character after it gets sent. Otherwise, both the client-escape character and the character following it are sent to the server as ordinary user input. 🎯

If the character after the client-escape is the dot ".", or the client-defined end-of-file character (usually control-D), the connection closes. The server normally treats this as a disconnection, not an orderly logout. 👋

Other characters (client-defined, usually control-Z and control-Y) are used to temporarily suspend the rlogin client when the host can do that. One character suspends both remote input and output. The other suspends remote input but lets remote output keep going to the local client's terminal. 🧘

Most client implementations have invocation switches that can defeat normal output processing on the client system. These can also force the client to stay in raw mode despite switching notification from the server. 🛠️

A Cautionary Tale [2] 🚨

Okay bestie, read this one carefully. It's the security part, and it's serious 💀

The rlogin protocol (as commonly implemented) lets a user set up a class of trusted users and/or hosts that are allowed to log on as themselves without entering a password. It's extremely convenient, but it's a weakening of security that has been successfully exploited in previous attacks on the internet. If you want to use the password-bypass facilities of the rlogin service, it's essential to realize what compromises may be possible. 😰

Bypassing password authentication from trusted hosts opens all the systems so configured when just one is compromised. It's like using the same password for every system you can access. It lets a villain in everywhere you have access. Allowing passwordless login among all your systems gives a marauder a wide playing field once they've entered any of your systems. 🏃‍♀️💨

Many people feel that one compromise achieves a workable balance between convenience and security. That's to allow password bypass from only one workstation to the other systems you use, and to not allow it between those systems. With this measure, you may have reduced exposure to a workable minimum. ⚖️

The trusted host specification is ordinarily just a host name. It's possible, by compromising your organization's domain name server or compromising your network itself, for a villain to make an untrusted host masquerade as a trusted system. There's little a user can do about this form of attack. Luckily, so far such attacks have been rare, and they often cause enough disruption to a network that attempts are quickly noticed. 🕵️

When the file containing a user's list of trusted logins is inadvertently left writeable by other users, untrustworthy additions may be made to it. 📂

Secure authentication extensions to the rlogin protocol (Kerberos, et al) can greatly reduce the possibility of compromise while still allowing the convenience of bypassing password entry. As these become more widely deployed in the internet community, the hazards of rlogin will decrease. 🔐✨

References 📚

[1] Stevens, W., "UNIX Network Programming", ISBN 0-13-949876-1.
[2] Garfinkel & Spafford, "Practical Unix Security",
    ISBN 0-937175-72-2.

Security Considerations 🔒

See the "A Cautionary Tale" section above. Seriously, go read it, it's the whole security story for rlogin 🙏

Author's Address 💌

Brian Kantor
University of California at San Diego
Network Operations C-024
La Jolla, CA 92093-0214

Phone: (619) 534-6865

EMail: brian@UCSD.EDU