"The Linux Gazette...making Linux just a little more fun!"

Really Wants 'rsh' to Work. Really

From Mike Hahn on Mon, 18 Oct 1999

Dennis,

I have read all I could find on rsh and getting it to work to no avail. I run a small CAD network and am in need of the rsh function. We are on a small private network so hacking is not really a consern. I run Mandrake Linux 6.0, Windows95/8/NT, IBM AIX, SUN Solaris, and DOS 6.2. I can rsh from to all machines exept the Linux boxes. I have tried all the suggestions in the "Answer Guy" columns that I could find. I did notice that in all of the "problems" the error message was "permission denied", what I am getting is "Connection Refused" Can you HELP?

Thank You.

M. Hahn Systems Admin.

What does the rsh line in your /etc/inetd.conf file look like?

It might be configured with command line options that prevent the Linux version of in.rshd from honoring certain types of .rhost file or force it to ignore /etc/hosts.equiv. Here's an example:

# /etc/inetd.conf:  see inetd(8) for further informations.
shell   stream  tcp   nowait   root   /usr/sbin/tcpd  /usr/sbin/in.rshd -h
login   stream  tcp   nowait   root   /usr/sbin/tcpd  /usr/sbin/in.rlogind

In this example the -h option was specified. That is a common setting on many Linux distributions. It means that "super user accounts may not be accessed through this service" (i.e. 'root' and any other accounts with UID=0).

If a -l option is specified than nobody's .rhosts file will be allowed. (Only the /etc/hosts.equiv would be consulted).

Read the in.rshd man page for all the gory details. Keep in mind that the Linux version of rshd is likely to be very picky about the forward and reverse hostname-IP address mappings (in a mostly futile attempt to foil spoofing).

One trick for testing these sorts of problems is to temporarily replace the in.rshd (or other inetd launched daemon) with a wrapper shell script that calls 'strace' with a command like:

strace -o /tmp/rshd.strace /usr/sbin/in.rshd.real $@

... and then try to connect to the service. After you get an error, login to the system using some other means and view the resulting "system call trace" file.

These 'strace' files can be difficult to read. However, you can usually take a pretty good guess as to what the problem is by watching for failures on open(), stat() and lstat() calls.

(This strace trick is useful for all sorts of problems, helping you isolate the missing configuration file or directory that some program is failing to find or unable to create/see. Of course I'd love to see a massive "error messages" project for Linux that would add patches to these programs to ensure that every distinct failure mode at a clear error message and every man page had an comprehensive list of the associated error messages and suggested coping strategies).

Good look.

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 48 December 1999

HTML transformation by of Starshine Technical Services, http://www.starshine.org/

					1	2	3	5
				5	6	7	8	9
10	11	12	13	14	15	16	17	18
19	20	21	22	23	24	25	26	27
28	29	30	31	32	33	34	35	36
37	38	39	40	41	42	43	44	45
46	47	48	49	50	51	52	53	54
55			56			57