another problem! MPICH

[Martin Siegert]

On Fri, Aug 03, 2001 at 08:04:01PM -0400, Eric Linenberg wrote:
> okay an update here:
> 
> I can rsh into a machine without using a password,
> eg rsh snickers, but if I do a "rsh snickers date", then I get a permission 
> denied error.
> 
> the thing is I when I built mpich i did ./configure -rsh=ssh so this should 
> not be an issue.   But if it is how is one to fix it?  On the other hand if I 
> do a "ssh snickers date" this works perfectly.

Here are a few tips for rsh:

# rsh <hostname>

is equivalent to 

# rlogin <hostname>

i.e., the settings/permissions for rlogin (not for rsh) are used! Only

# rsh <hostname> <command>

uses the settings/permissons for rsh.
Hence, to have the latter working without passwords you need something like

in.rshd : 192.168.1.

in your /etc/hosts.allow file (assuming that you have "ALL : ALL" in
/etc/hosts.deny and assuming that you are using the 192.168.1.0
network for communication/MPI) and the "shell" line - not the login line - 
must be enabled in /etc/inetd.conf. If you are using xinetd instead you
must enable rsh in /etc/xinetd.d/rsh (and not in /etc/xinetd.d/rlogin)
Furthermore, I prefer not to use .rhosts files (because they must be setup
for every user), but enter all cluster nodes in /etc/hosts.equiv on all nodes.

[I am assuming here that your nodes are on a private network like
192.168.1.0 or 172.16.0.0, etc. without ip-forwarding and similar; if they
are not, setting up rsh without passwords is a huge security risk].

Depending on your distribution (e.g., whether you are using inetd or xinetd)
you also may have to change settings in /etc/xinetd.conf, /etc/xinetd.d/rsh,
/etc/securetty, /etc/pam.d/rsh.

Also, if you want to use rsh without passwords as root different rules
apply (e.g., rsh as root ignores root's .rhost file and rsh as root
under RH7.1 only works when you add "rsh" to /etc/securetty - see the
little comment in /etc/pam.d/rsh).

I hope this helps. You may also want to check the error messages in
/var/log/messages and /var/log/secure (or whatever your distro is using) -
they sometimes give you a hint which program (tcpd, pam, etc.) is refusing
access.

Cheers,
Martin

========================================================================
Martin Siegert
Academic Computing Services                        phone: (604) 291-4691
Simon Fraser University                            fax:   (604) 291-4242
Burnaby, British Columbia                          email: siegert at sfu.ca
Canada  V5A 1S6
========================================================================