scp remote-to-remote implementation

[Sergio Gelato]

* Luis M [2005-05-24 12:30:08 -0400]:
> (Please when replying include my email since i'm not subscribe to this list)
 
> I always wanted to be able to copy from one remote location to another
> from a master server/workstation using something like:
>  scp [-r] server1:/path/to/dir server2:/path/to/dir2
> And have scp "know" that i mean to copy from server1 to localhost and
> from localhost to server2 or something of that sort. For as long as it
> is transparent to the end user.

(Un?)fortunately for you, that syntax already has the effect to make scp
copy the files from server1 to server2 directly (i.e., without going
through localhost). If there is direct connectivity between server1
and server2 and you've sorted out any credentials forwarding issues,
it could be both simpler and more efficient than sending the data
through localhost.

Also note that scp is meant to be a drop-in replacement for rcp, and
will probably not be developed beyond what is required for rcp compatibility.
If you are looking for a project, consider enhancing sftp instead.

I mentioned credentials forwarding issues. I find that things work smoothly
for me with either HostbasedAuthentication or GSSAPIAuthentication (with
credentials delegation enabled, of course). Less so with ssh-agent (I used
the -c option to ssh-add, and have agent forwarding turned off by default;
maybe it works when the default is ForwardAgent=yes). Presumably in an 
environment where such things are meant to be transparent to the end user 
you'll have the right settings in ssh_config.

> I also know that there is a better way of having this done (having a
> pipe created locally that automatically pipes things through from
> server1->localhost->server2

Is there any particular reason why you must go through localhost? The only
one I can imagine is if direct connectivity between server1 and server2
is poor or nonexistent.

Quick-and-dirty might be
	ssh server1 tar cf - -C /path/to/dir . | \
	ssh server2 tar xf - -C /path/to/dir2

Or maybe, if you can initiate the transfer from either server1 or server2,
you could use rsync with a suitable -e option ("ssh mitm ssh", where mitm
is a name by which these servers know your local host). I haven't tested
this; there might be a snag or two I've missed, hence the "maybe".