Responding to Greywolf, Andrew Brown, and Greg Woods, in turn.

Greywolf <greywolf@starwolf.com> wrote on Fri,  2 Jan 2004
at 11:19:38 -0800 in <Pine.NEB.4.51.0401021052490.17480@lothlorien.starwolf.com>:

> 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 <atatat@atatdot.net> 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 <atatat@atatdot.net>
> 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: receipts@daemon.org
> 
> >> >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
> >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.

Right. Sorry for the confusion.

Greg A. Woods <woods@weird.com> 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
of thing.

--jhawk