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

This document (3077223) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 10
 

Situation

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.

Resolution

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...

Additional Information

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.

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:3077223
  • Creation Date: 19-Oct-2006
  • Modified Date:23-Feb-2021
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.


SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center