Port 513 – RLOGIN (Remote Login)

Port 513 is the default port for rlogin (Remote Login), the BSD daemon (rlogind, also seen as in.rlogind) that opens an interactive login shell on a remote Unix host. What sets rlogin apart from a normal login is its trust model: if the connecting host and user are named in ~/.rhosts or /etc/hosts.equiv, rlogind hands over a shell with no password at all. When that trust check fails it falls back to a password prompt — but the password, and the entire session, then travel in cleartext. So an open port 513 is two problems at once: a passwordless-login path riding on spoofable host trust, and a sniffable terminal session. (Note that TCP 513 is login/rlogin; the separate UDP 513 assignment is who/rwhod, the old rwho service that broadcasts who is logged in — related, but a different thing.)

rlogin is one of the Berkeley r-services — the family of rexec (512), rlogin (513), and rsh (514) — that shipped with UNIX in the 1980s and were all replaced by SSH on port 22. rlogin is the interactive-login member of the set: where rexec always demands a username and password, rlogin (like rsh) leans on host-based .rhosts / hosts.equiv trust. That trust is exactly what makes 513 the classic lateral-movement target — compromise or spoof one machine in a trust group and the rest let you in for free.

Why It’s Open

Before SSH, rlogin was a standard way to get an interactive session on another UNIX box without retyping a password every time. It still turns up on legacy Solaris, AIX, HP-UX, and older Linux systems, on appliances and industrial gear running ancient firmware, and in lab images like Metasploitable 2 that ship the r-services on by default. Where port 513 is still listening it usually means an inetd/xinetd entry nobody cleaned up, a forgotten management path, or a box that hasn’t been touched since it was racked. On anything modern you should see SSH instead — and where 513 is open, its siblings rexec (512) and rsh (514) are usually one scan away.

Common Risks

• Passwordless login via host trust. The defining rlogin weakness: a ~/.rhosts or /etc/hosts.equiv entry that trusts a host (worst case, a wildcard + + line) lets a matching user log in with no password. Find a trusted or overly-broad entry and rlogin hands you a shell outright.
• Host and IP/DNS spoofing. Because the trust is keyed on the source host, spoofing the IP or poisoning the name resolution of a trusted machine can satisfy the check and bypass authentication entirely. This is the mechanism behind the famous rlogin trust-relationship attacks.
• Cleartext credentials and session. When rlogin does fall back to a password, that password and every keystroke cross the wire unencrypted — anyone on the path can sniff a full login with tcpdump or Wireshark.
• Weak or no auth + brute-force. Password fallback has no lockout or rate limiting, so guessing with hydra or Metasploit runs unimpeded.
• Session hijacking. There is no integrity protection, so an on-path attacker can inject into or take over an established session.
• Sibling trust abuse. rlogin ships alongside rexec (512) and rsh (514); finding 513 open almost always means the other two — and their .rhosts trust — are worth checking.
• rwho / rusers information leak. The related rwho service (rwhod, UDP 513) and the RPC-based rusers can enumerate who is logged in, handing an attacker valid usernames to target with the trust and brute-force paths above.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and grab the banner

nmap -sV -p 513 <target>

Brute-force with the nmap NSE script

nmap -p 513 --script rlogin-brute <target>

The rlogin-brute script must run as root, because rlogin trust depends on the client connecting from a privileged source port below 1024.

Connect with the native client

rlogin -l <user> <target>

If <user> is trusted via .rhosts / hosts.equiv, this drops straight to a shell with no password prompt.

Brute-force with Hydra

hydra -L users.txt -P passwords.txt rlogin://<target> -s 513 -t 4 -f

Metasploit login scanner

msfconsole -q
use auxiliary/scanner/rservices/rlogin_login
set RHOSTS <target>
set USERPASS_FILE userpass.txt
set STOP_ON_SUCCESS true
run

rlogin_login also needs to bind a privileged local port, so run Metasploit as root. On success it can open an interactive rlogin session.

Enumerate logged-in users with rwho

rwho -a

Log every open port 513, every trust relationship you find, and every credential that works as you go, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

rlogin’s real weakness is design, not a single patchable bug — the host-based trust, cleartext session, and no integrity protection are the exposure, and they don’t have a fix short of turning the service off. That said, a few genuine service-specific CVEs are worth citing:

• CVE-1999-0113 — “Some implementations of rlogin allow root access if given a -froot parameter.” The classic argument-injection flaw: rlogin -froot <target> smuggles a -f option through rlogind into login, which skips authentication and logs you straight in as root. Hit AIX, IRIX, and others (CVSS v2 10.0, CWE-88). Archived on Exploit-DB 19348.
• CVE-2001-0797 — Buffer overflow in login on various System V based operating systems (Solaris 2.x–8, and others), reachable remotely by passing a large number of arguments through services such as telnet and rlogin. Pre-auth remote code execution on vulnerable builds (CVSS v2 10.0).
• CVE-1999-0651 — “The rsh/rlogin service is running.” The legacy scanner finding that flags the r-services as present at all, precisely because a trust-based, plaintext login daemon is a risk by its nature (CVSS v2 7.5).

In practice the “exploit” is usually the trust model itself: find a permissive .rhosts / hosts.equiv entry (or spoof a trusted host), then rlogin -l <user> <target> for a passwordless shell — no memory-corruption CVE required. Treat any open rlogin as compromised-by-design and prioritize the trust files over chasing a specific vuln.

Mitigation

• Disable rlogin, rsh, and rexec entirely. There is no modern reason to run the r-services. Remove or comment out the login, shell, and exec entries in /etc/inetd.conf (or the matching xinetd files) and restart the super-server.
• Remove .rhosts and /etc/hosts.equiv. Hunt down and delete every stray trust file — they grant passwordless access even after you think the service is locked down, and a single + + line is a full bypass.
• Migrate to SSH. Move interactive login to SSH on port 22, which encrypts the whole session and supports key-based auth. ssh user@host is the direct replacement for rlogin, and SSH keys replace .rhosts trust safely.
• Block TCP 512–514 at the host and network firewall so nothing outside a trusted management range can reach the r-services, and block UDP 513 to shut down the rwho leak.
• Force credential rotation on any account that authenticated over rlogin — assume the password was sniffed.

Real-World Example

The r-services are a fixture of the Metasploitable 2 training VM, which leaves rexec (512), rlogin (513), and rsh (514) open with a wide-open /etc/hosts.equiv that trusts every host. The standard walkthrough is to point auxiliary/scanner/rservices/rlogin_login (or nmap --script rlogin-brute) at port 513, or simply run rlogin -l root <target> — and because the trust file accepts anyone, rlogind returns a root shell with no password at all. The same blind host trust is what made rlogin the engine of the 1990s trust-relationship attacks, where spoofing the IP of a trusted machine was enough to walk into every host that trusted it. It’s a compact demonstration of why the whole family was retired: host trust you can spoof, cleartext when you can’t, and a shell either way.

FAQ

What is port 513 used for?

TCP port 513 is the default for rlogin (Remote Login), a Berkeley r-service that opens an interactive login shell on a remote UNIX host. It was a pre-SSH way to get a session on another machine, often passwordless via host-based trust, and is now considered obsolete and insecure. (Separately, UDP 513 is assigned to who/rwhod, the old rwho service that reports who is logged in.)

Is port 513 dangerous?

Yes on any untrusted network. rlogin can grant a shell with no password when a host is “trusted” via .rhosts / hosts.equiv — and that trust is spoofable — while any password fallback and the whole session are sent in cleartext. Treat an exposed port 513 as something to close, not to harden.

What service runs on port 513?

The rlogin daemon, rlogind (or in.rlogind), one of the Berkeley r-services alongside rexec (512) and rsh (514). All three were replaced by SSH on port 22.

What’s the difference between rlogin and SSH?

rlogin authenticates by trusting the source host (.rhosts / hosts.equiv) and sends everything in cleartext, so it can be sniffed, spoofed, and hijacked. SSH on port 22 encrypts the session, verifies the server’s host key, and supports strong key-based authentication — which is why it replaced rlogin entirely.

How do I close port 513?

Disable the login entry in inetd/xinetd, remove any .rhosts / hosts.equiv trust files, migrate to SSH, and firewall TCP 512–514 (and UDP 513) to a management range. Rescan with nmap -p 513 <target> to confirm the port is closed.

TL;DR

• Service: rlogin (rlogind / in.rlogind) — interactive remote login, a Berkeley r-service
• Default port: 513/TCP (UDP 513 is the separate who/rwhod rwho service)
• Biggest risk: passwordless login via spoofable .rhosts / hosts.equiv host trust, plus a cleartext session
• Mitigation: disable rlogin/rsh/rexec, remove .rhosts / hosts.equiv, migrate to SSH, firewall 512–514