[Beowulf] passwordless rsh/ssh

[Robert G. Brown]

David Mathog writes:

>> Yes.  What does /etc/hosts.deny have in it?  ALL: ALL ?
> 
> It's empty (private subnet, so why not?)
> 
> /etc/hosts.allow has:
> 
> ALL: 192.168.1.0/24
> 
>> 
>> Also, rsh runs usually from xinetd.  in /etc/xinetd.d there should be an 
>> rsh, rlogin, and rexec file.  Do any of these have the word "yes" in the 
>> disable field?
> 
> rexec is yes, rsh and rlogin are no.  So I did the experiment: changed
> rexec to "no" as well, restarted xinetd.  Nope  the rsh -l form
> still fails.  Put rexec back the way it was.
> 
> It's an odd bug, rsh works for "fred", "sally", or "root", just not
> root -> fred or sally -> fred via rsh -l, when both of those
> work going to Solaris.
> 
> Anybody know where the home page for rsh-server is?  Maybe 0.17-13
> is old and the current version (not available from Mandrake updates)
> has this fixed?

Over the many years, I've spent a number of days cursing rsh and getting
this and that to work (ssh too).  And then you get it to work and --
they change it.  I mean one lovely feature of rsh was the symlink trick
-- if you symlink e.g. hostname -> /usr/bin/rsh then you can run remote
commands by just entering hostname command.  This worked for ssh too.
Then openssh decides no.  Similarly, one could ssh to hostname, run a
command in the background, and logout.  The background command would
disconnect from the tty and keep running.  Then openssh decided no to
THAT.  Suddenly it was much more difficult to use ssh to distribute
remote jobs, and for what?  Feature drift.

My guess (and it is only a guess) is that you're getting bitten by the
many layers of security that can control the same thing., probably PAM,
but possibly hosts.allow/hosts.deny and very possibly hosts.equiv.

I wish I could help more, but every time I've solved a problem like this
it has been by simply working my way through the layers until something
gives up and works.  ssh's debug mode made it a lot easier for that
tool, as it gives you a pretty good idea where it fails.  rsh is going
to be tougher.

I assume that you're not using e.g. kerberos?  That hostnames resolve
and so on (since .rhosts usually requires the ability to resolve,
right?).  IIRC, there USED to be a file in /etc that controlled whether
or not a system would permit root rsh's at all, but I haven't used rsh
for so long I can't remember what it was.  /etc/securetty?  Under some
circumstances this file could prevent root from getting a pty.

   rgb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.scyld.com/pipermail/beowulf/attachments/20050622/e41e13f1/attachment.bin