SUMMARY: rsh host command not working

From: Bill Fenwick (
Date: Thu May 29 1997 - 15:53:10 CDT

Hi, all

I've been sitting on this for about a month, so it's probably time to get a
summary out...

My original question was:

>We've got several Ultras running Solaris 2.5.1 and a Solbourne running SunOS
>4.1.2 . rsh works properly among all the Ultras and from the Solbourne to any
>of the Ultras, but it's exhibiting a strange symptom whenever I try to rsh from
>an Ultra to the Solbourne.
>From the Ultra, "rsh solstice" (solstice is the Solbourne) works acts
>like an rlogin and throws me into the appropriate home account. But whenever I
>try to run "rsh solstice command" it hangs for a minute and returns "connection
>refused". I searched the archives and found a similar problem that was solved
>when the user set up the .rhosts file to include the username field. Been
>there, done that, no effect.
>The solbourne is acting as an NIS slave server, with the NIS master server
>one of the Ultras. Somebody here was wondering if using the services file on
>the Ultra (through NIS) could cause a problem like this. Would it?

Many thanks to the following for their replies:

David Fetrow <>
Andreas Ehliar <>
Stephen Harris <>
Casper Dik <casper@holland.Sun.COM>
Steve <>
Viet Hoang <>
John Justin Hough <>
Sean Ward <>
Brian White <>
Pam Skaufel-Davidson <>
Peter L. Buschman <>
Jochen Bern <bern@TI.Uni-Trier.DE>
Marty Weghorn <>
Mariel Feder <>

Suggestions were:

Make sure that /etc/services has a line like

shell 514/tcp cmd # no passwords used

and /etc/inetd.conf has a line like

shell stream tcp nowait root /usr/etc/in.rshd in.rshd

to enable rsh.

Check to see if one of the machines is running the secure shell version of rsh.

Check rlogin and rsh hostname. If they both work, the .rhosts file is OK.

Be sure the destination host knows about your source host. Make sure each
interface name of the source host is in the destination hosts' /etc/hosts file
or can be resolved through DNS.

Check for commands in .login or .profile files that are trying to determine the
terminal type or set ttys. These have been known to screw up rsh.

Make sure there are no blank lines in /etc/services, as YP can choke on them.

rsh won't work on Solaris unless the user has an entry in the remote machine's
/etc/shadow file.

Is the machine running tcp_wrappers? (It wasn't)

Depending on how your /etc/resolv.conf for DNS is set up, you may have to enter
machines into .rhosts in any one of the following ways:

ip address

Make sure hosts.equiv on the remote machines has an entry that includes the
local machine. (If you're rsh-ing as a user other than root. As root, only the
..rhosts file is checked)

And Jochen Bern had a good list of things to try, which I'll reproduce:

ad 2) Installation of ssh on the Target Host doesn't affect its Ability
        to receive rsh Connections - you'ld have to turn that off manually
        (as per /etc/{services,inetd.conf}). Installation of ssh on the
        requesting Host may cause ssh to get tried instead (rather than in
        Addition to) rsh, but if the (ssh) Connection were actually refused
        by the Target Host, it *should* (unless configured differently,
        and again manually) fallback to rsh.
ad 1) Doublecheck that /etc/services has two Mentions of "rshd" (rather
        than the first being "tcpd" instead). Check that the given rshd
        is in Fact the OS's rshd (rather than a "Setup Type 1" tcpd;
        Personally, I think that this Setup Type is an Accident waiting
        to happen, PERIOD. Type 1 is to mv the real Daemon and replace
        it with a Copy of tcpd; Type 2 is to enter tcpd explicitly into
3) Are you using NIS(+)? If yes, the services Map will be used instead
        of /etc/services. In the same Idea, check all relevant
4) Any significant Differences in Network Topology? (I.e., some
        Network Device may be blocking rsh Connections ...)
5) Just for Debugging, try a simple "rsh host" (which falls back to
        "rlogin host", and, hence, actually uses a different Daemon).

What finally worked for me was removing the commands that were trying to
determine the terminal type from my .cshrc and .login files. Along the way, I
got a little suspicious about how well the Solbourne was functioning as an NIS
slave server, so I set it up as a client-only instead. The combination of those
two steps seems to have licked the problem.

Bill Fenwick                                     Email:
Digicomp Research                                Voice:  (607) 273-5900 ext 32

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:56 CDT