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 fine...it 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
being
>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 <fetrow@biostat.washington.edu>
Andreas Ehliar <dt95aneh@forsmark.uu.se>
Stephen Harris <sweh@mpn.com>
Casper Dik <casper@holland.Sun.COM>
Steve <skives@cantor.com>
Viet Hoang <vqh@dwrock.dw.lucent.com>
John Justin Hough <john@oncology.uthscsa.edu>
Sean Ward <seanw@amgen.com>
Brian White <brw@jazz.njit.edu>
Pam Skaufel-Davidson <pskaufel@mapquest.com>
Peter L. Buschman <plb@concentric.net>
Jochen Bern <bern@TI.Uni-Trier.DE>
Marty Weghorn <britt@tellabs.com>
Mariel Feder <unix.support@central.meralco.com.ph>
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:
solstice
solstice.digicomp.com
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
inetd.conf.)
3) Are you using NIS(+)? If yes, the services Map will be used instead
of /etc/services. In the same Idea, check all relevant
nsswitch.conf's.
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: fenwick@digicomp.com Digicomp Research Voice: (607) 273-5900 ext 32