ssh & rlogin work; rsh doesn't

We are doing some benchmarking on a cluster running Fedora Core 1.  We're having trouble getting rsh to work. (Before anyone says anything, yes, we know rsh is insecure.  This cluster is not hooked to the net, and we just want to run some tests with rsh.) ssh and rlogin work fine, but when we use rsh, we get Connection Refused errors after a long timeout period. Here are some of the things we've checked:

/etc/hosts.allow (listed below)
/etc/hosts.deny (listed below)
/etc/xinetd.d/rsh (listed below)
that xinetd is running
that rshd is installed and turned on (see chkconfig output below)
that iptables is turned off (see chkconfig output below)

Anyone got any ideas or sugestions of other things to check?


#
# hosts.allow      This file describes the names of the hosts which are
#             allowed to use the local INET services, as decided
#            by the '/usr/sbin/tcpd' server.
#

portmap: 192.168.1.0/255.255.255.0
lockd: 192.168.1.0/255.255.255.0
mountd: 192.168.1.0/255.255.255.0
rquotad: 192.168.1.0/255.255.255.0
statd: 192.168.1.0/255.255.255.0
in.rshd: 192.168.1.0/255.255.255.0
in.rlogind: 192.168.1.0/255.255.255.0
sshd: 192.168.1.0/255.255.255.0

#
# hosts.deny      This file describes the names of the hosts which are
#            *not* allowed to use the local INET services, as decided
#            by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular
# you should know that NFS uses portmap!

portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL
in.rshd:ALL
in.rlogind:ALL
sshd:ALL

# /etc/xinetd.d/rsh
#
# default: on
# description: The rshd server is the server for the rcmd(3) routine and, \
#      consequently, for the rsh(1) program.  The server provides \
#      remote execution facilities with authentication based on \
#      privileged port numbers from trusted hosts.
service shell
{
      socket_type            = stream
      wait                  = no
      user                  = root
      log_on_success            += USERID
      log_on_failure             += USERID
      server                  = /usr/sbin/in.rshd -h
      disable                  = no
}

Excerpted output from chkconfig --list:
iptables             0:off      1:off      2:off      3:off      4:off      5:off      6:off
xinetd               0:off      1:off      2:off      3:on      4:on      5:on      6:off
xinetd based services:
      chargen-udp:      off
      rsync:      off
      chargen:      off
      daytime-udp:      off
      daytime:      off
      echo-udp:      off
      echo:      off
      rsh:      on
      rlogin:      on
      services:      off
      time:      off
      time-udp:      off
      cups-lpd:      off
      sgi_fam:      on
      dbskkd-cdb:      off
      rexec:      off
LVL 1
jwolterAsked:
Who is Participating?
 
ahoffmannConnect With a Mentor Commented:
hmm, does netstat -an list port 514 with LISTEN on the remote machine?
0
 
yuzhConnect With a Mentor Commented:
you need to create a .rhosts file under your home dir

eg,
user fred want to use rsh from boxA to boxB
in boxB, you need to put .rhosts file under fred's home dir,
the file format looks like:
BoxA fred

0
 
ahoffmannCommented:
after checking ~/.rhosts and /etc/hosts.equiv enshure yourself that there is no firewall:
   iptables -L -n && iptables -L -n -t nat && iptables -L -n -t mangle
if in doubt, post results from above command
0
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

 
jwolterAuthor Commented:
Good things to look for.  I should have mentioned those in my post, because we've already looked at them. I'm posting the results of the iptables commands since I don't know much about iptables.  

I'm trying to use tcpdump to monitor the ports and determine where the process is breaking down.  if I do tcpdump tcp port 514 on node a10 and rsh a10 pwd on node a14, I get the following response:

08:52:19.585563 a14.1023 > a10.shell: S 3028079579:3028079579(0) win 5840 <mss 1460,sackOK,timestamp 23717916 0,nop,wscale 0> (DF)
08:52:19.585605 a10.shell > a14.1023: R 0:0(0) ack 3028079580 win 0 (DF)

This sequence then repeats every second or so until it times out.  I'm not sure where to go with this, though.

---

a10> iptables -L -n && iptables -L -n -t nat && iptables -L -n -t mangle
Chain INPUT (policy ACCEPT)
target     prot opt source               destination        

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination        

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination        

Chain INPUT (policy ACCEPT)
target     prot opt source               destination        

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination        
0
 
ahoffmannCommented:
iptables has no restrictions

silly question: does the user on a14 running rsh exist on a10? do they have the same uid?
0
 
jwolterAuthor Commented:
same user; same uid; same gid.  I've tried it with root and with a non-privleged user.  I've tried it between nodes.  I've tried it to the local node. None of these work.
0
 
jwolterAuthor Commented:
No! Since port 514 is the shell service in /etc/services, I assume this is a problem. Any guess how to fix this? Shouldn't xinetd be listening on this port (per the /etc/xinetd.d/rsh file listed above)?
0
 
jwolterAuthor Commented:
And the answer is:

I got curious so I shut down xinetd and restarted it from the command line with the debug option: /etc/rc.d/init.d/xinetd -d

In all the output, I found an error message that there were two arguments to server, when only one was expected. What it comes down to is that xinetd was barfing on the following line from /etc/xinetd.d/rsh:

     server               = /usr/sbin/in.rshd -h

It treats the "-h" as another argument.  I think it should look more like:

     server               = /usr/sbin/in.rshd
     server_args       = -h

but I haven't gotten this to work for root.  Works for non-privileged users, though!

Thanks everyone.  Time to allocate points...

0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.