scp won't handle remote -> remote file transfers that require password authentication

[Fraser Hanson]

The scp man page states that scp can perform remote system to remote system file transfers, but this does not appear to be working for me in breezy.

fhanson@fhanson:~$ scp root@192.168.170.61:mydir/file.tar.gz root@192.168.130.81:
Warning: Permanently added '192.168.170.61' (RSA) to the list of known hosts.
Password:
Warning: Permanently added '192.168.130.81' (RSA) to the list of known hosts.
Permission denied (publickey,keyboard-interactive).
lost connection
xfree: NULL pointer given as argument
fhanson@fhanson:~$

- I know I am entering the password correctly
- I can scp to/from both of these servers from my desktop machine (fhanson.)
- This is not an Ubuntu-specific bug: The result is the same on SuSE SLES 10, except that the xfree message is not printed.

[Björn Torkelsson (torkel)]

Are you allowed to connect directly between the two hosts?

Afaict, scp uses ssh to connect to the first host and then run scp from the first host to the second. If you are not allowed to connect between the hosts (and perhaps not using an interactive auth mechanism) it will not work.

Adding -v to the command should tell you what it actually is doing.

[Fraser Hanson (fraser-hanson)]

Yes, I can connect directly between the two remote hosts. I am using password authentication on all systems involved.

I used the -v option as you suggested, and it was helpful. It appears to be a tty related issue.

With that in mind, I have found that this command works as expected:
> fhanson@fhanson:~$ ssh -t 192.168.170.61 "scp tmp/myfile 192.168.130.81:"
> 192.168.130.81:
> Warning: Permanently added '192.168.170.61' (RSA) to the list of known hosts.
> Password:
> Password:
> myfile 100% 441KB > 440.5KB/s 00:00
> Connection to 192.168.170.61 closed.

output from scp -v follows:

scp -v root@192.168.170.61:/smart-0.41-15.i586.rpm root@192.168.130.81:
Executing: /usr/bin/ssh -v -x -oClearAllForwardings yes -n -l root 192.168.170.61 scp -v /smart-0.41-15.i586.rpm root@192.168.130.81:.
OpenSSH_4.1p1 Debian-7ubuntu4.1, OpenSSL 0.9.7g 11 Apr 2005
debug1: Reading configuration data /home/fhanson/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.170.61 [192.168.170.61] port 22.
debug1: Connection established.
debug1: identity file /home/fhanson/.ssh/identity type -1
debug1: identity file /home/fhanson/.ssh/id_rsa type -1
debug1: identity file /home/fhanson/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2
debug1: match: OpenSSH_4.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.1p1 Debian-7ubuntu4.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
Warning: Permanently added '192.168.170.61' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/fhanson/.ssh/identity
debug1: Trying private key: /home/fhanson/.ssh/id_rsa
debug1: Offering public key: /home/fhanson/.ssh/id_dsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_CA.UTF-8
debug1: Sending command: scp -v /smart-0.41-15.i586.rpm root@192.168.130.81:.
Executing: program /usr/bin/ssh host 192.168.130.81, user root, command scp -v -t .
OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug...

[Andrew Jorgensen (ajorg)]

I noticed this bug while looking at another one and tried it out. I kind of doubt it's an Ubuntu problem but it's definitely there. I use the ssh agent and agent forwarding to ensure that I can go between boxes at will. Tried out this feature and found that it just doesn't work no matter what I try.

[Andrew Jorgensen (ajorg)]

Er, no, if you use the agent it works, but it doesn't tell you it's working (aside from the 0 exit code). There isn't any progress bar for you to watch though.

[Colin Watson (cjwatson)]

It's not an Ubuntu problem; see the link in the "Remote bug watches" section for this bug to the upstream bug report.

[Barry deFreese (bddebian)]

This won't get fixed in Ubuntu. Thank you for the bug report.

[Colin Watson (cjwatson)]

Please leave this bug open until we have a proper status in this bug tracking system to indicate that it's been passed upstream.

[Colin Watson (cjwatson)]

Upstream say that they won't fix this bug, and offer the following explanation (see the remote bug watch link):

"After thinking about this some more, there is a good reason why this
patch should not go in: when you perform a copy "scp host_a:file
host_b" with this patch, you must expose your password on "host_a"
rather than the local host.

You may not trust "host_a" with your "host_b" password (e.g. someone
making a trojan scp binary there could easily collect passwords without
your knowledge), and it isn't obvious to someone without a good
knowledge of how this actually works that they are actually entering a
password on a non-local system.

Adding a warning is probably not practical because the host that
initiates a remote to remote copy doesn't know what authentication
mechanisms will be needed."

[Neal McBurnett (nealmcb)]

For those that didn't follow all the comments, note that the workaround is to use agent authentication. See the section on "Using the ssh-agent" in
https://help.ubuntu.com/community/SSHHowto