[Bug 1837] New: scp fails key auth/connection on second host when two remote paths are specified

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=1837

           Summary: scp fails key auth/connection on second host when two
                    remote paths are specified
           Product: Portable OpenSSH
           Version: 5.3p1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P4
         Component: scp
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: petiepooo at yahoo.com


When issuing a command such as
  scp host1:file host2:.
I observed public key authentication succeeding on host1, but failing
on host2.  It was through digging into the verbose output that I
discovered that commands formatted as such are essentially equivalent
to
  ssh host1 scp file1 host2:.
with the additional constraint that agent forwarding is explicitly
disabled through a -o option.

My expectation was that it would be more equivalent to
  ssh host1 tar cf - file1 | ssh host2 tar xf -
or using scp syntax, something like
  ssh -x -t host1 scp -f file1 | ssh -x -t host2 scp -t .
but I was unable to get that particular syntax to work.

The reasons for this expectation are:
1. agent forwarding: I may not trust host1, so don't want to forward my
agent onto that host, but still may need it for access to host2.
2. accessible networks: I may not be able to reach host2 from host1,
but can reach both hosts from the localhost I'm running scp on.
3. DNS resolution: host2 may resolve to different IPs on the localhost
versus on host1.  That difference would not be obvious to the user
without close examination of the verbose output.
4. Obvious test: "scp host1:file ." and "scp file host2:." both work,
but combining them into a single command does something completely
unexpected, and breaks.

I realize that, under the behavior I expected, the localhost running
scp would act simply as a conduit for two remote connections, which may
be perceived as wasting bandwidth on that host, but that behavior is
precisely what I needed, and is how I expected it to act based simply
on the format of the command.  If I had wanted to transfer directly
from host1 to host2, I would have run it's sensible equivalent of
  ssh host1 scp file1 host2:.

The bug summary is a little misleading, as it doesn't describe my
expectations as explained above, but it does show the symptom that led
to me filing this bug report.  My hope is that it will make searching
for the symptom easier for confused end users such as me.  Feel free to
change if you find a better way of summarizing this.

The tar solution allows me to work around this, so I wouldn't consider
this a severe issue.  Documenting this format more completely may be
sufficient, but as it is, there is no solution I know of using only
ssh/scp equivalent to what the tar solution gives me.  If most people
are like me, they wouldn't think using two remote paths would form a
chain from localhost to host1 then to host2; they would assume the path
is from host1 through localhost to host2.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.