Solved

ssh & rlogin work; rsh doesn't

Posted on 2004-08-05
8
1,785 Views
Last Modified: 2013-12-23
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
0
Comment
Question by:jwolter
  • 4
  • 3
8 Comments
 
LVL 38

Assisted Solution

by:yuzh
yuzh earned 50 total points
ID: 11732610
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
 
LVL 51

Expert Comment

by:ahoffmann
ID: 11733201
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
 
LVL 1

Author Comment

by:jwolter
ID: 11735901
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
 
LVL 51

Expert Comment

by:ahoffmann
ID: 11736211
iptables has no restrictions

silly question: does the user on a14 running rsh exist on a10? do they have the same uid?
0
Netscaler Common Configuration How To guides

If you use NetScaler you will want to see these guides. The NetScaler How To Guides show administrators how to get NetScaler up and configured by providing instructions for common scenarios and some not so common ones.

 
LVL 1

Author Comment

by:jwolter
ID: 11736486
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
 
LVL 51

Accepted Solution

by:
ahoffmann earned 250 total points
ID: 11736969
hmm, does netstat -an list port 514 with LISTEN on the remote machine?
0
 
LVL 1

Author Comment

by:jwolter
ID: 11737371
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
 
LVL 1

Author Comment

by:jwolter
ID: 11739047
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

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

Suggested Solutions

Some time ago I was asked to set up a web portal PC to put at our entrance. When customers arrive, they could see a webpage 'promoting' our company. So I tried to set up a windows 7 PC as a kiosk PC.......... I will spare you all the annoyances I…
Don’t let your business fall victim to the coming apocalypse – use our Survival Guide for the Fax Apocalypse to identify the risks and signs of zombie fax activities at your business.
Viewers will learn how to connect to a wireless network using the network security key. They will also learn how to access the IP address and DNS server for connections that must be done manually. After setting up a router, find the network security…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

708 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now