openssh bugs - May 2014 - [Bug 2243] New: scp ignoring ~/.ssh/config when both source and destination are remote hosts

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

            Bug ID: 2243
           Summary: scp ignoring ~/.ssh/config when both source and
                    destination are remote hosts
           Product: Portable OpenSSH
           Version: 6.6p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: scp
          Assignee: unassigned-bugs at mindrot.org
          Reporter: adam.wolk at koparo.com

Hi,

I think I stumbled on a bug while trying to copy some database backups
between two servers. Since both of the machines in question have only
key auth available and I don't want to put my key on neither one of
them I decided to copy over the data using scp since it supports having
both the source and destination as remote hosts.

One of the machines (build.koparo.com) is running ssh on a non standard
port and the second one is running on the default port. I decided to
add an entry to ~/.ssh/config for the build.koparo.com machine in order
to avoid any additional flags for the command while copying over the
files.

I tested my config file by doing a regular ssh to the build.koparo.com
machine without using the -p parameter and it worked correctly so I
issued the copy command and it failed with a lost connection.
>From there I did several more tests including only the machine running
on a non standard port and it seems that the config file is ignored if
both ends are remote.

[mulander at koparo ~]$ ssh -V
OpenSSH_6.6.1p1, OpenSSL 1.0.1g 7 Apr 2014

My ~/.ssh/config file stating that build.koparo.com runs ssh on port
5222

[mulander at koparo ~]$ cat ~/.ssh/config
Host build.koparo.com
        Port 5222

[mulander at koparo ~]$


Copy a remote file from ssh running on port 5222 - properly uses the
~/.ssh/config

[mulander at koparo ~]$ scp build.koparo.com:~/case962.patch ./
Enter passphrase for key '/home/mulander/.ssh/id_rsa':
case962.patch                                                          
                                           100% 1177     1.2KB/s  
00:00
[mulander at koparo ~]$

Copy a local file to remote ssh running on port 5222 - properly uses
the ~/.ssh/config

[mulander at koparo ~]$ scp case962.patch build.koparo.com:~/adam.txt
Enter passphrase for key '/home/mulander/.ssh/id_rsa':
case962.patch                                                          
                                           100% 1177     1.2KB/s  
00:00

Copy the same file (adam.txt) on the remote host renaming it to
adam2.txt - ~/.ssh/config seems to be ignored

[mulander at koparo ~]$ scp build.koparo.com:~/adam.txt
build.koparo.com:~/adam2.txt
Enter passphrase for key '/home/mulander/.ssh/id_rsa':
ssh: connect to host build.koparo.com port 22: Connection refused
lost connection
[mulander at koparo ~]$

Trying the -F flag to point at the config file directly:

[mulander at koparo ~]$ scp -F /home/mulander/.ssh/config
build.koparo.com:~/adam.txt build.koparo.com:~/adam2.txt
Enter passphrase for key '/home/mulander/.ssh/id_rsa':
ssh: connect to host build.koparo.com port 22: Connection refused
lost connection
[mulander at koparo ~]$


I can properly ssh to the machine - config file is read correctly
without me having to specify the port with -p.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Adam Wolk <adam.wolk at koparo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adam.wolk at koparo.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

--- Comment #1 from Adam Wolk <adam.wolk at koparo.com> ---
As reported by tkoskine on IRC it seems to be related that HOST a
config is taken into consideration.

The -3 option worked for tkoskine while tunelling traffic through his
own host. This hangs for me:

mulander at koparo move]$ scp -3 build.koparo.com:~/adam.txt
build.koparo.com:~/adam2.txt
Enter passphrase for key '/home/mulander/.ssh/id_rsa': Enter passphrase
for key '/home/mulander/.ssh/id_rsa':

Since I don't have a an ssh agent running.

Not sure if this is a bug or feature. I expected my client to negotiate
the connection (auth against both boxes) and both ends passing the data
after that.

Also the connection hanging with no indication is a bit problematic to
diagnose.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

engrenage <bugzilla.mindrot at engrenage.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
           Severity|normal                      |enhancement
                 OS|Linux                       |All
           Hardware|amd64                       |All
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla.mindrot at engrenage.
                   |                            |ch

--- Comment #2 from engrenage <bugzilla.mindrot at engrenage.ch> ---
$ scp user1 at host1:source user2 at host2:dest


When copying between two remote hosts, the host1 is _instructed_ to
copy files over to the second host using host1:~user1/.ssh/config and
the keys in the same directory. Local config is used to connect to
host1 in the first place, _not_ after.

Using -3 flag works fine with local config used for both hosts.


I would close this as INABIAF.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
You are receiving this mail because:
You are watching the assignee of the bug.