Hello
I need to use rsh but I can't do it on a server. I actually rsh to the server, but I can't from a new server.
I can rsh from server to other servers but i cant to server b. Problem is server b. I can also rsh to server b from other servers.
Server A to rsh server B ----> var/log/messages B server
server B firewall not active, iptables not active
xinetd[2545102]: START: shell pid=842131 from=::ffff:..........
xinetd[842131]: FAIL: shell address from=::ffff:.......
xinetd[2545102]: EXIT: shell status=0 pid=842131 duration=0(sec)
Server A rsh command
poll: protocol failure in circuit setup
It appears that the issue is with the xinetd service on server B. The log messages indicate that the shell service is failing to start when a connection is attempted from server A. It's possible that the xinetd configuration on server B is not set up to allow connections from server A. You should check the xinetd configuration file (usually located in /etc/xinetd.d/) and make sure that the shell service is allowed for connections from server A. Additionally, you should check the /etc/hosts.allow and /etc/hosts.deny files to ensure that server A is not being explicitly blocked from connecting to server B.
Welcome to the forum ! We hope you that you find this to be a friendly and helpful place, and that you enjoy your time here.
There are a few possible avenues of investigation here. Firstly, it would be very helpful to know more about your operating environment. At a minimum, knowing the operating system and its version for both servers would be very useful, as this would give us some idea of what options are available to you here, and of what type and age of software we're actually talking about.
The very first question I would ask is: do you absolutely have to use rsh ? Because if you don't, almost literally anything else would probably be better. The old remote login and remote shell daemons used to be a pretty standard way of logging in between trusted hosts on the same network. But these days, they have been almost entirely superseded by the secure shell, ssh. If you have an SSH client and server installed, these would be by far a better thing to use than rsh or rlogin.
However, if you absolutely must use rsh for some reason, then we can see what we can do to help. Does the error message you mention always appear every single time, or only sometimes ? How many other users are logged in via rsh or rlogin to Server B at the time you are getting the error ? And does logging in from Server A to any other hosts work at that time (i.e. you only get this error when logging in from Server A to Server B) ?
Lastly, network-wise these can be quite strange daemons, with TCP communication at certain points being required in both directions between the client and the server. You mention that no firewall is running on Server B - is there one running on Server A, and if so, could it be restricting connectivity back to it from Server B ?
If you can address the above questions, we can take things from there. But to recap once again: if you have any say in the matter at all, the best thing here is to ditch rsh entirely (going so far as to disable the service altogether), and to switch to SSH instead.
Yes, ssh is much more secure. By means of ssh keys you can run a command or a login without a passwords.
rsh and rlogin should never face the Internet. A firewall should block them.
If any server can run ssh serverB command
then the rsh service is enabled (rshd in xinetd).
Note that without command the rsh turns into an rlogin that is a different service (rlogind in xinetd).
On serverB, check the destination user's .rhosts file and the all-users /etc/hosts.equiv file.
The host in it must be exact as the serverB resolves it, i.e. getent hostsip_of_accessing_server
Is rshd running? pgrep -u 0 -l rshd || echo not running
Traditionally rshd is started "on demand" by the inetd or xinetd service. service xinetd status
Alternatively it can run as a regular service. service rshd status
chkconfig and service are traditional frontend commands. But most distros migrate to systemd and only maintain the service command, where service rshd status
runs a systemctl status rshd
So, to recap: you can use rsh on Server C to connect to Server B without any errors, but when you try to use rsh on Server A to connect to Server B, that's when you get the error. Is that definitely correct ?
If so, my next question would be whether these servers are all on the same network and sub-net, or are they located on different networks ? If they are all on the same sub-net and physical network then that should (in theory at least) rule out any intermediate firewall as a possible cause. But if, for example, Server C is in the same sub-net as Server B, but Server A is on a different sub-net, then there may still be a firewall in between the two networks that is filtering out the traffic.
Other than that, my next question would be if the versions of the rsh and rsh-server packages on each of the Oracle Linux 8 servers are identical ? I ask this because it seems strange to me that you can connect from the Oracle Linux 6 host to the 8 host without errors, but you can't connect successfully between the two 8 hosts. If anything I'd be more inclined to expect problems the other way around, than between two servers which should be running the same (and therefore compatible) software.
I added another server, server D > oracle linux 8.6
A server to D server RSH ->ok
C server to D server RSH ->ok
B server to D server RSH ->ok
D server to B server RSH -> poll: protocol failure in circuit setup
I think the problem is on server B. I wonder if there is a security issue on server B?
Because when I installed the first server, I added the servers that connect with rsh, but I can't add a new server.
One more thing to check then: do all the 8.6 servers have the same sets of updates installed ? If they don't, it would be good to make sure they're all at the same patch level. But my original questions still stand as well, regarding the physical and virtual networking setup that these servers are connected to.
Same patch level and network settings are the same. same dns, same gateway same wlan
We enabled iptables on server B, then we turned it off. I made the rsh connection of the C server to B server before iptables
I suppose then the next step is to check the logs for rshd on Server B. If you look at /var/log/messages and/or the journalctl output for the RSH server, do you see anything interesting at those times when these connection failures occur ?
EDIT: also, does this occur with all user accounts, or only some ? If you've only tried with one user account, can you try with another and see what happens ?
RSH Server C to server B rsh
xinetd[2545102]: START: shell pid=3800398 from=::ffff:serverC IP
rshd[3800399]: root@serverC IP as root: cmd='df -h'
xinetd[2545102]: EXIT: shell status=0 pid=3800398 duration=0(sec)
RSH server A to server B (all user same error)
xinetd[2545102]: START: shell pid=842131 from=::ffff:..........
xinetd[842131]: FAIL: shell address from=::ffff:.......
xinetd[2545102]: EXIT: shell status=0 pid=842131 duration=0(sec)
That last finding - that you can use rsh to log in and get a shell prompt fine, but that you can't use it to remotely execute a command - brings us right back round to network port issues as the primary suspect.
When you use the command format rsh <hostname> <command>, you are indeed using rsh as you might expect. However, when you simply run rsh <hostname> to get a shell prompt, you are not actually using rsh as a protocol. What ends up being used in this situation is the rlogin protocol, which is similar, but not the same. An rlogin session simply requires a straightforward TCP connection from the client to port 513 on the server, and that's all there is to that.
However, when you are using rsh to execute a single remote shell command, two separate network connections are required. First, the local system connects to the remote system on TCP port 514. The remote system will then try to call back to the calling system on a TCP port typically between 1016 and 1022, in order to handle the stderr output stream for the command that is being remotely executed. And if that part fails, that's what causes your "protocol failure in circuit setup" error.
If you have Red Hat support access, they have an article that covers this exact scenario, and explains things in a bit more detail:
So on both Server A and Server B, I'd double-check the iptables situation, and also make sure that firewalld is disabled. Also, check you have no other services running on ports 1016 through 1022 on both servers, since if you do, that could be the problem, in that the callback ports might be blocked.
One last final thought that just occurred to me: please also check the ownerships and permissions on /usr/sbin/in.rshd (the daemon that gets run in genuine rsh-and-not-rlogin situations on a RHEL-style system). On my test CentOS 7 system at least, it's owned by root:root, and has normal permissions of 0755. And if I re-name it or change its permissions so that it can't be executed, I also find that I get the "protocol failure in circuit setup" error, since the binary that needs to be run for the callback connection is failing to execute.
Okay, rlogin/513 works but not rsh/514, that rules out a mismatch of the resolved hostname versus the one in /etc/hosts.equiv or .rhosts
The above link to RedHat requires a subscription, I cannot read it.
Oracle is more open here:
(Well, it is written for Solaris, but many details are valid for Linux. For some reason the Linux man page is much too short.)
And this one states that the rshd (or in.rshd) checks the source ports.
So also check permissions of the sending /usr/bin/rsh binary. Maybe it needs a root suid bit to be allowed to use a port below 1024?
BTW as I understand there is no callback but a second callforward for stderr.