Better rsh with timeout option?

[Robert G. Brown]

On Fri, 8 Feb 2002, Jeff Layton wrote:

> Good morning,
> 
>    I've got some VERY simplistic scripts to loop over hostnames
> to execute a command on the nodes via rsh. However, there are
> times when the node responds to a ping, but you can't rsh to it
> (the node has basically swapped itself to death, but still responds
> to pings). The current rsh has no timeout option and I'm guessing
> the current timeout setting is very long (I have never bothered to
> find out what it is - I just kill the terminal window after about
> 5 minutes).
>    Does anyone know of a rsh with a timeout option? I searched
> the web pretty thoroughly and came up with zip (except for prsh
> but it is asynchronous, I want synchronous output :).

rgb at lucifer|T:125>time ssh lilith
Secure connection to lilith refused.
0.000user 0.010sys 0.0%, 0ib 0ob 0tx 0da 0to 0swp 0:15.18

(where lilith is a laptop that happens to be entirely off, so it doesn't
even ping).  In cases where the host pings but sshd happens to be turned
off it tries four times and then quits -- about four seconds.  I haven't
tried it when a host is hung in exactly the state you describe (pingable
so there is a route, but sshd nonresponsive but not quite dead because
of thrashing) but it seems likely that it would be handled somewhere
between these two extremes.

Evidently, ssh times out in about 15 seconds.  ssh is better than rsh is
so many ways.  In a loop script like this where times of order one
second are irrelevant, ssh will be basically indistinguishable from rsh
in overall time performance (there are differences of order 0.1 seconds
in latency associated with the ssh handshake and encryption, and you can
always turn encryption off if you are really worried).  ssh means that
you can even run your scripts over a WAN and not worry about security
risk.  There are a vanishingly small subset of tasks for which one MIGHT
consider using rsh instead of ssh -- something loop-scripted where the
overhead of the remote shell connection itself is the dominant consumer
of time -- but even then the real message is that remote shells are
likely a silly way to perform the task.  Then there are all the REALLY
cool features of ssh, like port forwarding (the ability to drive a hole
right through an annoying firewall, for example, without annoying the
systems person in charge of the firewall).  Probably irrelevant to your
script, but once you start using ssh generally you'll quickly learn to
use its advanced features as you need them.

So bag rsh says I, and use ssh instead.  Pretty much universally.

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu