1

I would like to copy a file with scp from host1 to host2 running the command from my local machine. The connection from host1 to host2 must use IPV4 because there is no IPV6 connectivity between host1 and host2 (for reasons outside my control).

From my local machine, I use:

scp -4 -v -r -o "ForwardAgent=yes" user@host1:myFile user@host2:

In the output, I have:

debug1: Connecting to host1 [a.b.c.d] port 22.

which is correct, but connection from host1 to host2 is attempted with IPV6:

debug1: Connecting to host2 [a:b:c:d:e:f:g:h] port 22

and it fails, because there is no IPv6 connectivity.

How to force scp to use IPV4 on the connection from host1 to host2?

P.S.: I use the scp from macOS 10.13.3

==== Edit

Below the full log. You can see that the problem comes from the fact that when scp send the command from host1 it doesn't add the -4 option. See the line:

debug1: Sending command: scp -v -r /myFile user@host2:.

.

OpenSSH_7.6p1, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /Users/user/.ssh/config
debug1: /Users/user/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /usr/local/etc/ssh/ssh_config
debug1: Connecting to host1 [a.b.c.d] port 22.
debug1: Connection established.
debug1: Local version string SSH-2.0-OpenSSH_7.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Debian-10+deb9u3
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to host1:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:/sfbwfbhwh/wsfgwhwthwth
debug1: Host 'host1' is known and matches the ECDSA host key.
debug1: Found key in /Users/user/.ssh/known_hosts:66
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to host1.com ([a.b.c.d]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Requesting authentication agent forwarding.
debug1: Sending command: scp -v -r /myFile user@host2:.
Executing: program /usr/bin/ssh host host2, user user, command scp -v -r -t .
OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l  25 May 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to host2 [a:b:c:d:e:f:g:h] port 22.
  • are you open to using rsync? – zee Mar 20 '18 at 14:09
  • The question is confusing. Is it using IPv4 or IPv6? – Rui F Ribeiro Mar 20 '18 at 14:12
  • @zee no problem to use rsync. – Ortomala Lokni Mar 20 '18 at 14:15
  • @RuiFRibeiro scp tries to use IPV6 between host1 and host2 but it fails because there is no IPV6 connectivity between host1 and host2. – Ortomala Lokni Mar 20 '18 at 14:16
  • 1
    I'm pretty sure you do have IPv6 connectivity, at least link-local. Otherwise it wouldn't try to connect using it, unless you have a badly misconfigured system. Does the address begin with FE80? Then it is a link-local address. – Johan Myréen Mar 20 '18 at 15:11
2

Try using: scp -4 -v -r -o "ForwardAgent=yes" user@host1:myFile user@d.e.f.g:

Where d.e.f.g is IPv4 address of the host2. And check your DNS, please, so it will return right addresses.

  • Ok this workaround works well. But the source of the problem comes not from a DNS configuration but from the fact that the scp command doesn't reuse the -4 option when it executes the command from host1. – Ortomala Lokni Mar 20 '18 at 14:51
  • OK, you maybe discovered a bug in OpenSSH (congratulations), nevertheless if you do not use IPv6 for the host2, DNS resolver should return IPv4 address of the host2. – Mikhail Zakharov Mar 20 '18 at 14:56
  • host2 is using IPV6, but is not reachable from host1 using IPV6. – Ortomala Lokni Mar 20 '18 at 15:07
0

This should do it. Hope I understood you correctly :)

$ rsync -rav --ipv4 /tmp/f.txt  someuser@dev1:/home/someuser

from man rsync

 -v, --verbose               increase verbosity
 -a, --archive               archive mode; same as -rlptgoD (no -H)
 -r, --recursive             recurse into directories
 -4, --ipv4                  prefer IPv4
  • Ok, but what about agent forwarding (-o "ForwardAgent=yes")? – Ortomala Lokni Mar 20 '18 at 14:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.