Subject: Re: Policy questions
To: Andrew Brown <firstname.lastname@example.org>
From: John Hawkinson <jhawk@MIT.EDU>
Date: 01/02/2004 12:29:46
Andrew Brown <email@example.com> wrote on Fri, 2 Jan 2004
at 12:05:30 -0500 in <20040102120530.B27092@noc.untraceable.net>:
> >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
I don't see the relevence of that. Yes, it is true.
> 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.
> > . 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.
> >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
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
> i don't even remember what the original issue was.
Then go back and read the thread, please.