Subject: Re: Policy questions
To: Greywolf <firstname.lastname@example.org>
From: John Hawkinson <jhawk@MIT.EDU>
Date: 01/02/2004 20:48:10
Responding to Greywolf, Andrew Brown, and Greg Woods, in turn.
Greywolf <email@example.com> wrote on Fri, 2 Jan 2004
at 11:19:38 -0800 in <Pine.NEB.firstname.lastname@example.org>:
> To restate it simply:
> - we need a new remote-access utility which will provide zero data encryption
> by default, while requiring true user authentication.
> Did I miss anything?
No. I don't want a remote access utility; ssh is fine for that.
The point is a way for users who already have access to two machines
(e.g. via ssh) to build a channel between the two machines and transfer
data over that channel.
This is exactly what you get with netcat on both machines.
Andrew Brown <email@example.com> wrote on Fri, 2 Jan 2004
at 15:10:33 -0500 in <20040102151033.A27981@noc.untraceable.net>:
> Date: Fri, 2 Jan 2004 15:10:33 -0500
> From: Andrew Brown <firstname.lastname@example.org>
> To: John Hawkinson <jhawk@MIT.EDU>
> Cc: tech-userlevel@NetBSD.org
> Subject: Re: Policy questions
> Message-ID: <20040102151033.A27981@noc.untraceable.net>
> In-Reply-To: <20040102172946.GS5290@multics.mit.edu>; from jhawk@MIT.EDU on Fri, Jan 02, 2004 at 12:29:46PM -0500
> X-Hi-To-All-My-Friends-In-Domestic-Surveillance: hi there, sports fans :)
> Return-Receipt-To: email@example.com
> >> >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.
It's not a complaint. It's the necessary precondition for the desired
tools. Does that help? :)
> >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
> 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.
Right. Sorry for the confusion.
Greg A. Woods <firstname.lastname@example.org> wrote on Fri, 2 Jan 2004
at 14:37:26 -0500 in <m1AcV6s-0002T7C@proven.weird.com>:
> Well unless one assumes SSH is both installed and configured and running
> in a usable fashinon, and is also "good enough security", I don't think
> that's possible, or even realistic.
For purposes of this problem, I'm happy to assume that. (Or that the
user has secure console access to both machines. etc.)
> > When I've had this need, I end up kludging something with tar and
> > netcat on both ends, but it's not very satisfactory, especially since
> > netcat's semantics combine the idea of timeouts with exitting when the
> > connection closes (i.e. "-w secs").
> Unless you can securely confirm the integrity of that file transfer
> (e.g. using a secure hash that you transmit out-of-band, which in effect
> is a form of crypto, so doesn't really fit your scenario)
Low-overhead crypto is fine, and I think qualifies. The real point is
to not drop transfer speeds from O(10mbps/sec) to O(2mbps/sec), etc. When
I've done this, I usually md5 the files on both ends and assume that's
good enough, which it has been for my applications.
Ideally if we actually had a tool for this, it could handle that kind