RSH stands for Remote Shell and originally appeared on the early UNIX platforms. RSH is used to execute commands on a computer running the rshd daemon from another computer. Windows XP and above includes this utility in the default OS installation.

The security used by rsh is considered to be basically non-existent for the following reasons:

• No passwords are used, only usernames
• The username and IP address of a system running the rsh command can easily be duplicated/spoofed in order to gain access to a remote system running the rsh server
• There is no encryption used between the rsh client and server

The following example shows running a couple of remote commands:

The authentication process between the rsh client and server explained:

The rsh server has a local username, remote username, and an allowed IP source address of every connection allowed to it.

• Local username means the name local to the RSH server.It isn’t defined on a Cisco router in the sense of a traditional local username/password entry. It’s basically just a random word that could be considered as a ‘shared secret’ between the server and client. What is defined here has to match was it being used with the –l option in the rsh client.
• The remote username is the name of the logged in user running the rsh client. This username is taken from the currently logged in user that is running the RSH command. If being run as a process, it uses the defined user that is setup to run the command. You can’t manipulate this in the rsh client, it automatically uses the username from the Operating System. In Windows the rsh command just uses the user name with no <domain>\ or <computername>\ prefix.
• The IP source IP address is the address of the machine running the RSH client.

As you can see from the previous explanation, all the information that is really needed to execute commands on a remote rsh server is the local username and which remote usernames and IP’s the server allows. The last two items as previously mentioned, can easily be duplicated from an normally unauthorized computer.

Here is the output from the debug command – debug ip tcp rcmd:

An unsuccessful attempt

%RCMD: [514 <- 10.1.100.20:1023] recv 1022\0
%RCMD: [514 <- 10.1.100.20:1023] recv Administrator\0Administrator\0show run\0
%RCMD: [514 <- 10.1.100.20:1023] recv -- Administrator 10.1.100.20 Administrator not in
trusted hosts database
%RCMD: [514 -> 10.1.100.20:1023] send <BAD,Permission denied.>\n

In the above attempt, there is not a local user called Administrator on the router, thus the request is denied.

A successful attempt

%RCMD: [514 <- 10.1.100.20:1023] recv 1022\0
%RCMD: [514 <- 10.1.100.20:1023] recv Administrator\0Router\0show run\0
%RCMD: [514 -> 10.1.100.20:1023] send <OK>

Steps for configuring a Cisco device to support RSH:

Router(config)#ip rcmd remote-host Router 10.1.100.20 Administrator enable
Router(config)#ip rcmd rsh-enable
Router(config)#no ip rcmd domain-lookup

The previous configuration example allows a host with the IP address of 10.1.100.20 that is logged into the Operating System as the user Administrator to run commands on the device using rsh. Notice the use of the no ip rcmd domain-lookup command. Without this, the router will attempt to do a reverse lookup on the incoming source IP address and will fail if the reverse dns entry does not exist, so in our example scenario, we turn off this behavior. If we had left it on in our test environment the rsh execution would have failed with the following debug output:

%RCMD-4-RCMDDNSFAIL: DNS hostname/ip address mismatch.  10.1.100.20 unknown to DNS

If you need to allow a single user to come from multiple source IP addresses, use an access list in the rcmd configuration as shown in the following example.

Router(config)#access-list 1 remark Source IP addresses allowed to use RCMD
Router(config)#access-list 1 permit 10.1.100.20
Router(config)#access-list 1 permit 192.168.100.20
Router(config)#ip rcmd remote-host Router 1 Administrator enable
Router(config)#ip rcmd rsh-enable

RSH is currently used between Cisco products to serve certain functions. CiscoWorks, which is a Network Management System, uses rsh to run certain processes on Cisco devices that it manages. Also, various Cisco VoIP platforms use rsh to execute commands on routers as needed.

In my opinion, if this type of access could be used in your network, consider only allowing a secured, centrally located computer the ability to execute rsh commands on your network devices. By having a physically and logically secure station that is allowed to run rsh, you stand less of a risk of someone being able to steal it’s identity for replication on an unauthorized computer.