Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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 +++
share|improve this question
    
Are you certain you reverted everything back to initial state? Did you restart your daemon? –  Mat Mar 18 '13 at 10:50
    
Yes I rebooted. –  devnull Mar 18 '13 at 11:07
    
What about my first question? –  Mat Mar 18 '13 at 11:08
    
Yes I am sure that I revert back all the changes. –  devnull Mar 18 '13 at 11:09
    
@Mat What is the reason of this isssue? –  devnull Mar 18 '13 at 11:20
show 2 more comments

1 Answer

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.

share|improve this answer
    
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. –  devnull Mar 19 '13 at 4:33
    
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 5: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. –  devnull Mar 19 '13 at 6: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 7: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 7:15
show 7 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.