Bug#508613: more info

[Peter Dillinger <pcd@ccs.neu.edu>]

By the way, the manual claims to support this kind of operation:

  "Copies between two remote hosts are also permitted."

It appears from the -v output that the way it tries to process

  scp host1:file1 host2:file2

is to ssh to host1 and execute this there:

  scp file1 host2:file2

Indeed, if host2 is a custom "Host" name only configured in .ssh/config
on host1, it uses that.


The way this form should be implemented (IMHO) is like

  ssh host1 'cat file1' | ssh host2 'cat > file2'

(but with support for multiple files, etc.)

This way, the meaning of "host1" and "host2" are simple, and it
actually makes something that is kind-of difficult--copying from one
host to another through the localhost--much easier.  This is actually
a useful thing for many reasons, including (1) we can use a local agent
to authenticate with both hosts, and (2) host2 might not to even be
addressable by host1. (intranet!)

Basically, I believe it is stupid for scp host1:file1 host2:file2 to
DIRECTLY copy between host1 and host2, because that is already easy:

  ssh host1 scp file1 host2:file2

That is easy to figure out, easy to write, and easy to understand.
The current shorter version (scp) is immensely confusing, since "host2"
is specified with respect to "host1".

Oh, and the shorter version is generally broken because there's no
means of interactive authentication between host1 and host2.  But with
the ssh form, we can fix that easily:

  ssh -t host1 scp file1 host2:file2

Now it actually works, in the way we expect!