[clug] scp alternative

[James Polley]

On Sat, Apr 11, 2009 at 4:19 PM, George Bray <georgebray at gmail.com> wrote:

> On Sat, Apr 11, 2009 at 3:19 PM, Daniel Pittman <daniel at rimspace.net>
> wrote:
> > George Bray <georgebray at gmail.com> writes:
>
> >> Does anyone know of an alternative solution where I get the
> >> client/host authentication of ssh, but don't get the CPU overhead of
> >> encrypting and compressing the payload?
> >
> > Um, why do you want the client and host authentication?  Is there really
> > a security risk that someone will insert incorrect video into the target?
>
> I need the clients to authenticate to the server to start the
> procedure, but once it's running I don't care about MITM issues.
>

Define "authenticate". I'll get back to this below...

>
> >> PS - I'm trying to avoid fileshares/mounts for robustity over long
> >> times.
> >
> > Unless your hosts are changing IP address then NFSv3/TCP should be
> > sufficiently robust for your needs — assuming that this is also WRT
> > authentication and/or connection relability?
>
> That was my first thought, but I've been warned against building 24/7
> systems that rely on mounts staying up all the time. It's not that the
> network is unreliable, the recommendation was more about detecting and
> recovering from failures being more complex with mounts vs individual
> copy sessions.
>
> I didn't mention it in my original post, but I want the ability for an
> admin server to issue commands for copying files between a number of
> remote servers. That's where I started with scp.  rsync is a brilliant
> package, but it can't do remote-remote copying.


I've only spent about 30 seconds thinking about this, so there probably
holes in what I'm about to suggest, but..

Presumably you have some kind of trust relationship between the machines,
such that the "admin server" is going to have the abilitiy to send commands
to all the remote servers to tell them which files to send where.

it's a little bit of work, but you could expand this to do everything you
need:
 - talk to remote Server B. Tell it to start an rsync listening on port X,
chrooted into directory Y, accepting connections only from Server A, all
defined in a non-advertised module called Z.
 - talk to Server A; tell it to rsync files from directory F to server A in
module Z on port X

There's some level of authentication between the hosts right there: A has to
know the right port number and module name. Add a time limit on B so that it
stops listening after 10 seconds if it doesn't have a connection yet.



>
> So I think I'm heading for rcp instead, which can apparently
> authenticate using kerberos.


rsync can use ssh as a transport, or rsync-protocol, but you've already
rejected these for various reasons.

However, rsync can also use rsh, and if you've got kerberized rcp (and are
happy with that level of authentication), why not just tell rsync to use
rsh? No encryption, you've said you're happy with kerberos for auth, and you
still get the benefits of rsync (which may, in fact, be negligible - I don't
know what your traffic patterns will be).



>
> Thanks for the discussion, and the off-list comments.    CLUG is a
> powerful brains trust, even on a lazy easter weekend!
>
> --
> George Bray, The Australian National University, Canberra, Australia.
> --
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux
>