rlogind and rshd are the remote login and remote shell daemon. These so-called r services use TCP ports 513 and 514, respectively. The RLOGIN protocol is described in RFC 1282 and RSH in RFC.

The r services were developed at Berkeley to provide seamless ("Look, Ma—no password") authentication between trusted hosts and/or users.

Authentication between client and server is based on the client IP address, TCP port, and client username. The client IP address and username must match an entry in either the system-wide trusted hosts file (/etc/hosts.equiv), or a user trust file (~/.rhosts). An additional so-called safeguard is that the client connection must originate on a reserved TCP port—as only programs running with root privilege can do.

The r services are very popular with end-users and administrators, as manual entry of the password is not required (unlike with TELNET). Unfortunately, they are terminally insecure.

r Services Risks

Security of the r services is based on an extremely weak authentication model.

Authentication is based on weak credentials, the source IP and TCP port. The source IP and TCP port can be forged. The original designers assumed a trusted network. Even the UNIX man page for these commands recognizes this fact.

Combined with predictable sequence numbers, crackers had a field day with these services.

The following post gives a line-by-line account of a real hack where the weakness of rsh was exploited: http://www.cs.berkeley.edu/~daw/security/shimo-post.txt

Countermeasures

Avoid the r-services totally—switch to SSH. This protocol is just plain broken from a security perspective. Expend your security efforts on bigger rocks (for example, host hardening and security patching).