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.
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...
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.
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
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com