4.21.1. The RSH protocol

RSH has a dual channel architecture. The client establishes a connection to the RSH daemon (rshd) and sends a user name and a command to execute. This channel becomes the standard input and output of the executed command. An optional second channel is initiated by the daemon to transfer standard error messages.

Warning

Both channels are plain text and completely insecure.

The protocol uses the following steps:

The client initiates a connection towards the server. At this stage the client sends an optional port number where it listens for a connection used for transferring the standard error stream. These ports must be between TCP/513-1023, this is verified by both the client and the server. The server initiates a connection to this port if one is specified. Both connections must originate from TCP ports 513-1023. As this is the only security measure in the protocol, both the server and client check it strictly.

Most server implementations verify the name and the address of the client using 'host' and 'gethostbyname' commands. If the verification is not successful, the server aborts the connection with a "Host address mismatch" message. This feature can be important if the original client address is not forged.

The client sends his/her username on the client machine. Username can be up to 16 characters long.

The client sends his/her username on the server machine. Username can be up to 16 characters long.

Rshd validates the user using the file /etc/hosts.equiv and the .rhosts files found in the user's home directory. Users list the allowed client hosts and user IDs in their homes (in $HOME/.rhosts).

Rshd executes the command, returns its standard output in the command channel and sends the standard error in the error channel.

Finally, the client closes the connection.