Error: "poll: protocol failure in circuit setup" using RSH to execute commands

Remote system is configured with the firewall active with the following ports allowed: shell login exec

Local system is configured with the firewall active with the following ports allowed: shell login exec

 

When using rsh to access and execute commands on remote hosts (such as "rsh remotehost command"), the system hangs for a long period of time, then returns the error:

poll: protocol failure in circuit setup

 

Disabling the firewall on the local machine allows commands to be executed successfully.

 

Using rsh to remotely login to a server (such as "rsh remotehost"), the login is successful immediately, with no error message.

When using the "rsh hostname" syntax (with no command), the local system connects to the remote host over TCP port 513 (login). Since this port is open on the remote system, this is sufficient for the traffic to be allowed by the firewall on the remote system and the user is permitted to login. All traffic appears to be passed back and forth between the two systems on port 513, and the originating port on the local system.

When using the "rsh hostname command" syntax, the behavior is somewhat different. The local system connects to the remote host over TCP port 514 (shell), then sends an RSH message with a TCP port number. This port number is a port on the local system that RSH opens for the remote system to connect back on. In other words, the local system tells the remote system to call it back on a different port. It doesn't appear to actually use the connection for anything, but a connection must be established before the requested "command" will execute. When the connection is successful established, the local system sends"command" request to the remote system on port 514, with the command response on the same port combination. Once the command is finished, both the connection from the local system to the remote system on port 514, and the remote system connection to the local system on the negotiated port are shut down.

The problem this creates is that the local system firewall must be configured to allow the remote system to connect back to it on the negotiated port. In all of the tests performed, the negotiated port was between 1016 and 1022. So, for this to work properly in the "rsh hostname command" syntax, the local system (the one on which the rsh command is run from) needs to allow inbound connections on the ports negotiated in the initial RSH packet. Again, tests showed these were always between 1016 and 1022, however this may not always be the case. While the complete port range used for this process has not been confirmed, it is presumed to be between 1011 and 1023 as these ports are listed in a block of "reserved" ports in the /etc/services file.

To configure this range of ports in the Firewall setup (via YaST), include the TCP port range 1011:1023. This will open the entire block of ports on the local system, allowing the rsh commands to execute properly. At least, this was the behavior observed during local tests...

For this to work "properly", the firewall would need to know about the RSH protocol, watch for the outbound packet with the negotiated port number, then dynamically allow that port back in from the specified remote host for the duration of the rsh session. IPTABLES is not designed to work that way... For this they invented true firewalls with protocol helpers.

Another way that this same functionality could be achieved is by using SSH instead of RSH... SSH functionality is very similar, allowing either a remote login to a host (as with the "rsh hostname" syntax) or remote command execution (as with the "rsh hostname command" syntax). SSH is a much more secure protocol as all traffic between the hosts is encrypted, and only uses a single port (TCP 22) for all communication between the systems. To provide the ability to execute a command without having to supply a password, public-private key pairs can be created and placed on the appropriate systems. If possible, it is recommended that this method be used instead, reducing the complexity of the setup while providing increased security.