Port 513: rlogin/rwho — The Trust Protocol

Port 513 carries two different services depending on the protocol. On TCP, it runs rlogin (remote login). On UDP, it runs rwho (remote who). Both are part of the Berkeley r-commands suite—a collection of Unix utilities built on a foundational assumption that turned out to be catastrophically wrong: that everyone on the network could be trusted.

What Runs on Port 513

TCP port 513: rlogin¹ Remote login with automatic authentication. Think Telnet, but with a feature that seemed convenient in 1982: if your username and hostname were in the remote system's .rhosts file, you could log in without entering a password.

UDP port 513: rwho² The "remote who" service. Unix systems would broadcast information about who was logged in, making it easy to see which users were active across your local network. The rwhod daemon would listen on UDP 513 and share login details with anyone who asked.

Both services share the same fatal flaw: they send everything in plaintext and trust whatever the client tells them.

How It Works

rlogin (TCP/513)

When you connect to a remote system via rlogin, the protocol works like this:³

1. Client connects to TCP port 513

2. Client sends four null-terminated strings:

   • An empty string (single zero byte)
   • The client username
   • The server username
   • The terminal type and speed

3. Server checks if this connection should be trusted:

   • Is the source hostname in /etc/hosts.equiv?
   • Is the source user/host combo in the target user's ~/.rhosts file?

4. If trusted, you're logged in. No password required.

5. If not trusted, you get a password prompt.

The protocol provides "a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output"—basically a better terminal experience than Telnet offered at the time. But at what cost.

rwho (UDP/513)

The rwhod daemon runs on Unix systems and broadcasts user login information:⁴

• Who's logged in
• What host they're connecting from
• When they logged in
• System load averages

Any system on the local network can listen to these broadcasts and build a picture of network activity. Convenient for system administrators. Also convenient for attackers doing reconnaissance.

The Story

In 1982, the Computer Systems Research Group at UC Berkeley was working on integrating TCP/IP into Unix. The research team—including Sam Leffler, Bill Joy, and Robert Fabry—created the r-commands to make it easier to work across multiple Unix machines in their lab.⁵

This was a world of maybe a few hundred Unix systems, most of them at universities and research labs, all operated by people who knew each other or knew someone who knew someone. Trust wasn't naive—it was contextually appropriate.

The r-commands premiered in BSD 4.1 and were fully incorporated into 4.2BSD released in August 1983.⁶ They spread rapidly because they solved real problems: copying files between machines (rcp), running commands remotely (rsh), logging in without typing passwords over and over (rlogin).

Bill Joy had left Berkeley in 1982 to co-found Sun Microsystems, but his earlier work integrating TCP/IP into BSD around 1980-1981 formed the foundation these tools were built on.

The r-commands specification was documented in RFC 1282 in December 1991,⁷ but by then the Internet had already changed. What worked for a research network of trusted colleagues was actively dangerous on a public network of strangers.

The Security Problem

The r-commands have multiple serious vulnerabilities:⁸

Everything is plaintext Usernames, passwords (when needed), commands, output—all transmitted unencrypted. Anyone with a packet sniffer on the network can read everything.

Authentication is a lie The protocol trusts the client to honestly report:

• What hostname it's connecting from
• What username it's running as
• What source port it's using

A malicious client can forge all of this. If I can make my packets look like they're coming from a trusted host in your .rhosts file, I'm in. The protocol has no mechanism to verify the client is telling the truth.

Broadcast reconnaissance The rwho service helpfully broadcasts who's logged in where, giving attackers a map of targets and usernames to try.

The Replacement

In 1995, Tatu Ylönen released SSH (Secure Shell) after watching passwords fly across his university network in plaintext.⁹ SSH does what rlogin does—remote login and command execution—but with encryption and actual authentication.

By the late 1990s, SSH had entirely supplanted rlogin and the other r-commands on Internet-connected systems. The r-commands survived longer on internal corporate networks where the trust model still (sort of) made sense, but even there, security audits eventually killed them.

Why Port 513 Matters

Port 513 is a timestamp. It marks the moment when the Internet's foundational assumption—mutual trust—stopped being viable.

The Berkeley r-commands were not poorly designed for their context. They were extremely well designed for a small network of cooperating Unix researchers. But the Internet didn't stay small, and it didn't stay cooperative.

Every time you use SSH and see "The authenticity of host can't be established," you're seeing the lesson port 513 taught us: never trust what the other side claims to be.

Related Ports

• Port 22 — SSH, the protocol that replaced rlogin
• Port 23 — Telnet, rlogin's contemporary (also plaintext, also obsolete)
• Port 512 — rexec (remote execution), another r-command
• Port 514 — rsh/syslog (remote shell and system logging)