>> >The devil is in the details. I'm not sure what the best tool for this
>> >sort of thing is, but I guess a netcat-style tool is the most generic
>> >and flexible.
>> 
>> netcat is probably not the "best" too, since one can also use rdist or
>> rsync or rdump or something, depending on what you're doing, but
>> netcat is certainly a damn good tool to have around.
>
>Err, no. rdist and rsync and rdump all require an rsh-style channel.
>The point I am trying to make is that:
>
>	.	rsh cannot be configured to provide a channel for these
>		tools without providing login access, which is
>		unacceptable.

but in order to run netcat on both ends, you have to have logged in
anyway.  besides, isn't it possible to get those programs to use ssh
instead of rsh rather easily?

>	.	ssh cannot be configured to provide a channel without
>		high encryption overhead, which is undesirable.

ssh can be compiled to offer cypher=none, but most people leave that
out either for fear that having such a thing would cause people to use
it, or because rsh can already provide no encryption.

>netcat can solve this problem. I'm not sure what other tools can
>(other than gssftp, with "PROT CLEAR").

i think we are getting far afield of the actual issue here, which is
that netcat is a good thing to have, and i think we both agree on
that.  there will always exist times when all you want is to blt a
large chunk of data from machine a to machine b and all you want to
know is that it got there.  when i'm dumping (and gzipping) my /usr
partition to another machine for backup purposes, netcat fits the
problem very nicely.

i don't even remember what the original issue was.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."