>> >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.
>
>I don't see the relevence of that. Yes, it is true.

you said, roughly, "these tools cannot be used with providing login
access".  i said "you have to log in to both sides to use netcat".
therefore, i don't see the relevance of of your complaint that they
can't be configured without providing login access.  *something* needs
to have login access in order to do anything with any of these tools.

>> besides, isn't it possible to get those programs to use ssh instead
>> of rsh rather easily?
>
>Again, the whole point here is that a file transfer mechanism is 
>desired that does not have the overhead of encryption. It cannot
>be done with stock ssh.

okay, fine.

>> >	.	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.
>
>Requiring users to modify the tools is not an acceptable solution.
>Also, I'm given to understand there are good protocol-specific reasons
>not to allow cypher=none, but I don't fully understand them.

okay, fine.

>> >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.
>
>Well, no. The issue that I raised is that we ought to have a tool to
>allow unencrypted file transfers without allowing unencrypted logins,
>and that netcat was the only tool I knew of that usefully allowed it.
>If there are other tools in common usage, I'd like to know what they
>are.

okay, i see.  because you log in and then effectively set up the file
transfer on a different channel, whereas the other tools like to log
in themselves.  once you put it that way, it's much clearer.

>> i don't even remember what the original issue was.
>
>Then go back and read the thread, please.

ah, yes.  "should we remove the r* commands?"  "no, they are still
useful to many people."

-- 
|-----< "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."