I have one big file on server
one and I want to copy it to server
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.