RFC 1258

BSD Rlogin 🎀

RFC: 1258 💖 Series: Network Working Group Author: Brian Kantor, Univ. of Calif San Diego Date: September 1991 Status: provides information for the Internet community, and does not specify an Internet standard Obsoletes / Updates: nothing listed in the title block

Okay bestie, this is the RFC for rlogin, the remote login thing that's been around forever! 🧚 It's an older document, so it's a little rough around the edges, but the vibes are immaculate.

---

Status of This Memo ✨

This memo documents a protocol and a common implementation that are already extensively used on the Internet 🌐 It's giving "this is already real, we're just writing it down" energy. It provides information for the Internet community. It does not specify an Internet standard 🙈 Distribution is unlimited, so share away 💜

Protocol Description 🦋

rlogin is a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output 🍓 It's super popular between Unix hosts because it carries more of the Unix terminal environment semantics than Telnet does. On lots of Unix hosts, it can also be set up so you don't have to type a password when connections come from trusted hosts 🔑

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

Connection Establishment 🌸

When the connection is established, the client sends four null-terminated strings to the server 💌 The first one is an empty string (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 "got it, we're now in data transfer mode" ✨ Window size negotiation may follow this initial exchange. More on that below 🪄

From Client to Server (and Flow Control) 💅

To start, the client begins in "cooked" mode (as opposed to "raw" mode). In cooked mode, the START and STOP characters (usually ASCII DC1,DC3) are 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 soon as it's typed. (But check the local-escape stuff below, it's its own whole thing 😉)

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

Screen/Window Size 📐

The remote server lets the client know it can accept window size change info by requesting a window size message. It does this right after the connection is set up and the user identification exchange is done. The client should reply to that request with its 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 gets sent to the server. It shows the current dimensions of the client's window, in case the user process on the server wants to use that info 📏✨

The window change control sequence is 12 bytes long. It has a magic cookie (two consecutive bytes of hex FF) 🪄, then two bytes of lower-case ASCII "s". Then come 8 bytes holding 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. Everything is 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 be processed before it's shown (tabs expanded, etc.) 📺

The server can slip single-byte control messages into the data stream. It does this by inserting the control byte into the stream and pointing the TCP "urgent-data" pointer at it 🫣 When the client receives 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. Then the control byte that was pointed to is received and interpreted like this:

• 02: a control byte of hex 02 makes the client discard all buffered data received from the server that hasn't been written to the client user's screen yet 🗑️
• 10: a control byte of hex 10 commands the client to switch to "raw" mode, where START and STOP are no longer handled by the client and are treated as plain data instead 🧸
• 20: a control byte of hex 20 commands the client to resume intercepting and locally processing START and STOP flow control characters 🔁

All other values of the urgent-data control byte are ignored. In every case, the byte the urgent data pointer points to 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 do an orderly shut-down. That means restoring terminal modes and notifying the user or processes of the close before closing the connection in the other direction 🫶

Implementation Notes 🛠️

The client defines a client-escape character (customarily the tilde, "~"). It's only handled specially 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 character nor the character following it gets sent. Otherwise, both of them get sent to the server as ordinary user input 📨

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

Other characters (client-defined, usually control-Z and control-Y) temporarily suspend the rlogin client when the host has that ability 💤 One 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. Those switches can also force the client to stay in raw mode, even after the server sends a switching notification 🚨

A Cautionary Tale ⚠️

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 typing a password. It's super 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 rlogin, it is essential to understand the compromises that may be possible 🙈

Bypassing password authentication from trusted hosts opens ALL the systems so configured when just one is compromised. 💀

Just like using the same password for every system you can access 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 gotten into any one of them 🦹‍♀️ One compromise that many feel achieves a workable balance between convenience and security is to allow password bypass from only ONE workstation to the other systems you use, and 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 by 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 these attacks have been rare, and they often cause enough disruption to the network that attempts get noticed quickly 🚨

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 skipping password entry 🔐 As these get more widely deployed in the internet community, the hazards of rlogin will decrease 🌟

Security Considerations 🔒

Bestie, this section is short but it's a big deal, so please read the thing it points to 😤 See the "A Cautionary Tale" section above.

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