In the past, the way in which
scp worked, when called (naively) to copy files between remote systems, was very inconvenient: if you wrote, for instance
scp user1@remote1:/home/user1/file1.txt user2@remote2:/home/user2/file1.txt
scp would first open an
ssh session on remote1, and then it would run
scp from there to remote2. For this to work, you would have to set up the authorization credentials for remote2 on remote1.
The modern way to do it, instead, ("modern" because it was implemented only a few years ago, and perhaps not everybody has a
scp) requires two steps. The first necessary step is to use
~/.ssh/config to set up all options for the connection to both remote1 and remote2, as follows:
This way it becomes possible to pass all necessary options to the command without ambiguities: for instance, if we had said on the CLI use port 2222 without the above configuration, it would have been unclear whether we were referring to remote1 or to remote2, and likewise for the file containing the cryptgraphic keys. This way the CLI remains tidy and simple.
Secondly, use the
-3 option, as follows:
scp -3 user1@remote1:/home/user1/file1.txt user2@remote2:/home/user2/file1.txt
-3 option instructs
scp to route traffic through the PC on which the command is issued, even though it is a 3rd party to the transfer. This way, authorization credentials must reside only on the issuing PC, the third party.