I have one big file on server one and I want to copy it to server two using scp. I have the keys setup properly and I can ssh/scp to both servers from my desktop.

The file I need to copy is larger then the free space on my workstation's hdd, so I wanted to do:

scp one:/opt/bigfile.tar.gz two:/opt/bigfile.tar.gz

but I got:

ssh: Could not resolve hostname one: Name or service not known

We do not have DNS here (don't ask me why), so I have this in my ~/.ssh/config:

Host one
    Hostname        <IP address of server one>
    User            jspurny

Host two
    Hostname        <IP address of server two>
    User            jspurny

If I try with a smaller file and transfer it from one to my workstation and then to two, it works fine:

scp one:/opt/smallerfile.tar.gz .
scp smallerfile.tar.gz two:/opt/

When using IP addresses directly as suggested in comment, I got:

$ scp jspurny@<one's IP>:bigfile.tar.gz jspurny@<two's ip>:bigfile.tar.gz
Host key verification failed.
lost connection

Not an issue:

The size is not an issue here - it was only a "trigger" to this problem as there was no way to store bigfile.tar.gz on my workstation. The problem occurs regardless of the file size.


Why does the command:

scp oneremote:file secondremote:file

throws an error regardless if using .ssh/config aliases or directly using ip addresses?

Solved - sort of - still looking for explanation - I've split the bigfile into smaller files and transfered them one by one through my workstation. I'm still wondering why it didn't work. So I would still appreciate some explanation of what was wrong ..

Found a reason why it fails: It seems I was being foolish. I thought that the command

scp one:file two:file

was creating two connections to each server and then receive data from one and immediately send them to two and thus acting like a relay.

This is clearly not the case, because a simple -v option revealed that it in fact just connects to one and from one it tries to connect to two. Which obviously isn't possible because server one is not supposed to connect to two.

  • Did you try just changing your scp command to use the IP addresses instead such as "scp jspurny@ip_address_server_one:/opt/bigfile.tar.gz jspurny@ip_address_server_two:/opt/bigfile.tar.gz".
    – user44337
    Commented Aug 2, 2013 at 11:05
  • @tchester: I did now, but it gives just a different error (see edited question)
    – Jan Spurny
    Commented Aug 2, 2013 at 11:14
  • related? unix.stackexchange.com/questions/14187/…
    – slm
    Commented Aug 2, 2013 at 11:59
  • @slm no, I have no problems with size.
    – Jan Spurny
    Commented Aug 2, 2013 at 12:51
  • As I've found the explanation of the errors, I wanted to add/accept it as my own answer, but it seems to me a bit unfair as it actually doesn't solve the problem. Do you think I should rephrase question into: How to copy file from server one to server two using my workstation as a relay? or should I add my explanation of my unability to use --verbose option as an answer and accept it?
    – Jan Spurny
    Commented Aug 2, 2013 at 15:18

4 Answers 4


Full credit for this answer goes to https://superuser.com/a/602436/142948

You need the -3 option for scp:

scp -3 one:/opt/bigfile.tar.gz two:/opt/bigfile.tar.gz

-3: Copies between two remote hosts are transferred through the local host. Without this option the data is copied directly between the two remote hosts.


Otherwise the 2nd alias "two" is being resolved on host "one", which may not exist.

  • Unfortunately, this option seems to be fairly new and propagated to all distros yet. Commented Oct 21, 2014 at 16:04
  • Thanks, it works on Ubuntu 20.04.3 LTS (Focal Fossa)
    – iheggie
    Commented Feb 20, 2022 at 12:50
  • I don't want to use local host as intermediary. I am trying this for Akamai CDN host where I am trying to copy existing dir to new location on same host. Wondering how it can be done.
    – videoguy
    Commented Feb 3, 2023 at 0:09
  • Seems this should be accepted answer. Commented May 17, 2023 at 18:31

Simple pipe

Try this:

ssh one 'cat file' | ssh two 'cat > file'

The first one should send the file content to your machine, while the second should send that on to second machine. I would compute a checksum at both ends after the transfer, to ensure that nothing got lost or garbled along the way.

Elaborate tunnels

For more elaborate applications, you could use ssh tunnels. For example, you could try something like this:

ssh -R 5001: one
ssh -L 5002: two

Then you can open a connection on one to machine localhost port 5001 and it will be forwarded twice and end up as a connection on two to localhost port 22. This is the ssh port, so you can use this for yet another scp, or for rsync, or whatever. You could also start an rsync server on two, and forward port 873 instead of 22. Or you could use nc on both sides to transfer raw data, using an arbitrary port number.

The main benefit between the above approach is that you have a two-directional tcp connection between the two machines, instead of a one-directional pipe only. That way, the two parties can exchange information, which is particularly important in the rsync case.

  • 1
    Thanks! This doesn't do exactly what I wanted, but what I actually needed, which is great.
    – Jan Spurny
    Commented Aug 5, 2013 at 12:27
  • I choose this option because of its advantage that it allows to append data with >>
    – ñull
    Commented Feb 22, 2023 at 13:24

Since you have user access to the source server (one) why not login and run your scp command on that server directly... If you worry that it will take too long, then start the command inside a screen then detach from the screen with Ctrl+a d and let it run.

However, if you must do this from your workstation, and SSH keys from source to destination server are working OK, then send the scp command as the parameter of an ssh command, like:

ssh user@source 'scp /path/to/file user@destination:/path/to/file'
  • Thanks, that would definitely work, except those servers both have disabled PasswordAuthentication and I can't add keys from one to another - they shouldn't be able to connect to each other.
    – Jan Spurny
    Commented Aug 2, 2013 at 13:00

Searching for the error message: "Host key verification failed." would seem to be the most straightforward thing to do here. I found this Q&A on askubuntu titled: SSH connection problem with “Host key verification failed…” error.

One of the answers to that Q&A suggested that the issue lied with a conflicting entry in your ~/.ssh/known_hosts file. You can either delete the troublesome entries from that file using any text editor or you can use this command to remove entries:

$ ssh-keygen -R hostname

Where hostname would be either the IP address or the name of the server you're attempting to connect from. All the above would be on host two by the way.

  • I'm not sure if I understand. I can ssh to one and two servers from my workstation without any problems.. the problem starts when I run scp one:file two:file from the workstation. And there are is no known_hosts file either on one or two. I just tried to remove keys for two (even for one to be sure) on my workstation but nothing changed (except for are you sure y/n propt).
    – Jan Spurny
    Commented Aug 2, 2013 at 14:52
  • @JanSpurny - your referring to your workstation has been a bit confusing in this Q, at least to me. When you say that you mean your laptop/desktop. So you're doing something like this when you say that it "works": scp workstation:file one:file and workstation:file two:file? Obviously you don't have to say "workstation:file" I'm just saying it explicitly for the conversation's sake.
    – slm
    Commented Aug 2, 2013 at 14:55
  • Well what I ment is that I ran all commands from my workstation. So it was more like: workstation$ scp one:file file and workstation$ scp file two:file. Anyway, I think I've solved it. I'll add it as my own answer.
    – Jan Spurny
    Commented Aug 2, 2013 at 15:06
  • @JanSpurny - OK, glad you figured it out. Thanks for the question BTW!
    – slm
    Commented Aug 2, 2013 at 15:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .