4

In the starting rsh worked properly, but after making some changes it shows some error [changes are shown in the end of this question, see that], I am sharing the same.

Command

$ /usr/bin/rsh localhost ulimit -n

Output

poll: protocol failure in circuit setup

After facing this problem, I followed this link, but didn't get any help.

It works properly, but when I made some changes, from this link, then after that it shows the output as above. Now I revert all changes, but it shows the same output. Why?

These are the lines that I added in files, showing in left hand side, by seeing the above link.

/etc/pam.d/login:       session    required     pam_limits.so
/etc/pam.d/sshd:        session    required     pam_limits.so
/etc/pam.d/su:          session    required     pam_limits.so
/etc/pam.d/system-auth: session    required     pam_limits.so

Here is the link of what I am trying to do.

Edit No. 1

strace -o log.txt rsh localhost pwd, some lines of output are as, 

connect(3, {sa_family=AF_INET, sin_port=htons(514), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
bind(4, {sa_family=AF_INET, sin_port=htons(1022), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(4, 1)                            = 0
write(3, "1022\0", 5)                   = 5
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=3, revents=POLLIN|POLLERR|POLLHUP}])
write(2, "poll: protocol failure in circui"..., 40) = 40
close(4)                                = 0
close(3)                                = 0
rt_sigprocmask(SIG_SETMASK, [], [URG], 8) = 0
exit_group(1)

Edit no. 2

Command - strace ~/rshd.trace in.rshd

Output

execve("/usr/sbin/in.rshd", ["in.rshd"], [/* 22 vars */]) = 0
brk(0)                                  = 0x2b3054ec2000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b303671d000
uname({sys="Linux", node="jhamb.XXX.XXX", ...}) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b303671e000
arch_prctl(ARCH_SET_FS, 0x2b303671e6d0) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Community
  • 1
devsda
  • 427
  • 3
  • 10
  • 19

2 Answers2

5

rsh is an exceptionally weird protocol which features one wrinkle that's quite unusual (I think non-PASV ftp is the only other TCP-based protocol I've seen it with): after opening a connection to the server, the server has to open a TCP connection back to the client. This is because the rsh protocol returns standard output via the regular TCP connection and standard error via this weird back-channel connection.

Obviously this works very, very poorly in these days of ubiquitous firewalls. I suspect that some firewall between you and the target server is rejecting that back-channel connection. Some firewalls have rsh protocol state tracking to allow this, but even if that's available, it's often not turned on.

This (among many other reasons) is why rsh is dying and everyone is switching to ssh, which has a much better-designed (although more complex) protocol that multiplexes multiple output streams over the same connection.

This is why your first link says to turn off iptables; it's disabling the firewall that's blocking that back-channel connection.

rra
  • 310
  • 1
  • 5
  • But this first link did not able to solve my problem. I understand what you said. But my problem is to start rsh by any how, because of some project reasons. Please help me in that. – devsda Mar 19 '13 at 04:33
  • 1
    Oh, doh, sorry, I completely missed your original command was contacting localhost. Hm. Then, yes, the firewall problem that almost always causes this may not be what you're running into. From your original message, the strace is saying that your client is getting an error from the server. What I would try to do is hook up the server so that it runs under strace (with `-o` pointing to some file in `/tmp`) to capture what's happening on the server. – rra Mar 19 '13 at 05:36
  • Actually I am doing localhost, server and client are the same machine. So what I am understand from comment is, run a command `strace rshd localhost pwd`. Because rshd is a rsh server. Am I right ? If I am wrong then correct me , Please. – devsda Mar 19 '13 at 06:46
  • Normally, `rshd` is being run from `/etc/inetd.conf` or some similar facility (perhaps a file in `/etc/xinetd.d`). That file will specify running `rshd` or `in.rshd` or something along those lines. I propose changing that invocation to `strace -o /root/rshd.trace rshd` instead. (You may have to check the syntax for your specific inetd configuration file for the right way to do this; if you say what inetd you're using, I can help.) – rra Mar 19 '13 at 07:14
  • Oh, and then re-run your `rsh` command, and look in `/root/rshd.trace` and see what it says. Somewhere in there is going to be an error, followed by it closing the client connection. – rra Mar 19 '13 at 07:15
  • Check Edit no. 2, it shows your instructions. – devsda Mar 20 '13 at 04:57
  • Oh, wow, okay, rshd is just segfaulting. And basically before it does anything. The rshd on your system seems to be really broken. Where did this rshd come from? Are the rsh and rshd from matching implementations? – rra Mar 20 '13 at 05:15
  • rshd is in `/usr/sbin/in.rshd`. I got this by running `grep rshd xinetd.d/*` – devsda Mar 20 '13 at 05:31
  • No, I mean, where does that in.rshd binary come from? Is it from a package from a Linux distribution? Which one? Not all rsh client and rshd server implementations are compatible, although I've never seen it segfault before. Wherever that rshd came from, it seems to be buggy.... – rra Mar 20 '13 at 06:17
  • It is from `netkit-rsh-0.17`. I already mentioned that it runs fine earlier(before making changes), but I made some changes, and after that I revert all that changes. It shows error: `poll: protocol failure in circuit setup`. The changes are mentioned in question. Please see that. – devsda Mar 20 '13 at 06:21
  • Oh. I saw that you said you'd made changes, but I had assumed that they were to your system configuration. I hadn't realized that you were changing the source of the rsh client and server. I'm afraid that the chances are extremely high that you didn't actually revert all of your changes -- either the server or the client is still modified and you've introduced a bug. I'd start again from the completely unmodified source. – rra Mar 20 '13 at 06:47
  • Ohk, Wait 2 minutes, I am doing cross check from original settings. – devsda Mar 20 '13 at 06:49
0

Causes :

Problem is Multi rsh is running in same time.

Solution :

Restart the rsh ,

service xinetd restart

Thinakara
  • 1