[Beowulf] passwordless "rsh" login

[Jakob Oestergaard]

On Fri, Jul 09, 2004 at 01:43:51PM -0400, Robert G. Brown wrote:
...
> > Please elaborate, I prefer rational arguments to orders.
> > What is wrong with rsh, what is much better with ssh?
> > A few words explanation would help.
> 
> If you search the list archives, I've written a few thousand words on
> this three or four times.  Things wrong with rsh:
> 
>  a) no security (as in "bleeding wound" in an open network)

No worse than the MPI/PVM jobs you're already running in your cluster.

Anyone else ever looked at the internals of something like mpich?   :)

>  b) no environment passing

Yes, that kinda sucks - but actually, I work in such an environment
every single day and I have not yet missed environment passing.

Oh, yes, one exception; I wanted my DISPLAY variable passed around - I
fixed it with a combined .xsession and .bashrc hack  (writes my DISPLAY
variable to a file when I start my X session, .bashrc reads it back when
I rsh to a remote node, problem solved).

>  c) no tunnelling/port forwarding

For what?  (on your cluster I mean - I know of good uses for port
forwarding elsewhere - but on a compute farm?)

>  d) no intrinsic X11 support

This is a good thing, believe it or not  :)

If my DISPLAY variable is set, the remote node will connect *directly*
to my local X server, the X authentication is in place (because of NFS
home directory), and everything works perfectly.

Besides, I can rsh to machine 'a', then to 'b', then to 'c', then to
'd', and then I can fire up an mplayer - and it will still display full
screen video on my terminal with no performance problems.

If rsh "supported" X11, this wouldn't be possible.

rsh is right in keeping it's dirty little hands off of my X11 traffic :)

>  e) archaic and easily spoofed/snooped authentication mechanism (see a))

So you don't use NFS?

I use NFS and NIS and rsh.  If I did this on a world-accessible network
I would be mad - I may still be mad but I fail to see how the known
security weaknesses of these protocols is a problem on a closed
physically secure network with trusted users ;)

>  f) terrible passwordless login control

rsh with a netgroup in /etc/hosts.equiv is no worse than NFS in my
oppinion. Which, of course, would be insane to run on an open network.

>  g) more or less frozen, unsupported code

Agreed. This kinda sucks.  But then, on the other hand, except for
environment passing I can't really see a lot of things that should be
changed.

The good thing about the horribly frozen code is, that my rsh works just
as well between my Debian and Gentoo machines, as it does from Gentoo to
AIX4.3 or some archaic version of Tru64.

That is probably not a priority on your average cluster though  ;)

> 
> Things good about rsh:
> 
>  h) relatively fast

Yep.  And then the 'bad' points above that I argued were really
qualities :)

> 
> Things good about ssh:
> 
>  a) strong security
>  b) environment passing
>  c) port tunnelling/forwarding
>  d) intrinsic X11 support
>  e) strong host authentication
>  f) strong personal authentication
>  g) bidirectional encryption, not easily snooped
>  h) good passwordless login control
>  i) currently being supported

No argument there - these are definitely qualities of SSH.

I just don't need them on my heterogenous closed physically secure
switched fast ethernet with trusted users :)

...
> In most cases your intrinsic limitation is going to be the speed of a
> pseudo tty interface, not ssh.  Simply writing to an xterm/console
> window is slow -- almost certainly MUCH slower than the speed with which
> ssh can encrypt/decrypt data.

It's pretty common for me to do things like:
*) rcp foo remote:/tmp
*) tar cf - foo | rsh remote tar xCfp /tmp -

etc.  (on the closed network only of course)

I would get *nowhere* near wire speed with scp/ssh.

I still do the above with ssh/scp as well, when accessing remote
networks. It's not that SSH is bad - I'm just arguing that in some very
limited scenarios, rsh is "better".

> Of course for real parallel operations, one doesn't use ssh (or any
> shell) to do real internode communications -- at most it is for out of
> band control operations like starting up pvm or mpi itself on remote
> nodes.  Or one writes a nice raw socket interface, or whatever.  ssh is
> fine for typical remote/interactive use on a cluster.

Oh the irony - starting up an MPI/PVM job with ssh  ;)

Sort of like wearing safety goggles when dismantling rusty old soviet
warheads  ;)

I'm not trying to bash ssh here - I use it every day and there's a lot
of things I couldn't do without it. It's a fantastic tool with a great
number of uses. I'm just trying to argue for "the right tool for the
job" - and in my humble oppinion there are definitely still a nonzero
number of jobs where rsh just beats ssh hands down.

Hey, Fortran still has its uses too, I'm told
  (ducks head and runs  ;)

-- 

 / jakob