4

I have two remote servers which have the same user and id keys. I can freely SSH to either of them from a local machine, or from one to the other. I ssh-ed to 100.100.100.1 and I tried to run:

scp -i ~/keyfile -r ognjen@100.100.100.1:/path/1/ ognjen@100.100.100.2:/path/2/

It returns the publickey error from the destination remote and a lost connection.

I accidentally realized that this works:

scp -i ~/keyfile -r /path/1/ ognjen@100.100.100.2:/path/2/

Why does the first fail?

2 Answers 2

8

Important note: The machine you call "local machine" is totally irrelevant. The real story begins when you're already on 100.100.100.1. In the context of scp and in the context of this answer "local" is the machine where scp is invoked by you.

Why does the first [command] fail?

You tried to copy between two (formally) remote hosts. scp recognizes ognjen@100.100.100.1:/path/1/ as a non-local path. It doesn't matter ognjen@100.100.100.1 points to the local machine. The tool doesn't (and shouldn't) check if an address that looks remote points to the local machine. Just by referring to the source as if it was remote, you made scp treat it as remote. Also the destination was remote.

Copying between two remote hosts can be done with or without the -3 option:

-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. […]

(emphasis mine, source)

The bold fragment applies to your case (even if your scp doesn't support -3).

If you use -v with your first command

scp -v -i ~/keyfile -r ognjen@100.100.100.1:/path/1/ ognjen@100.100.100.2:/path/2/

you will see scp connects from the local host to the source host ("incidentally" being the same host) using the key specified with -i. (Apparently the host is configured to accept this key, probably because the other server uses an identical key to connect.)

Then you will see another scp is invoked on the source host. The command is:

scp -v -r /path/1/ ognjen@100.100.100.2:/path/2/

-v and -r are there because they were in your local command. The source path is translated to a local path; the destination is unchanged. If this command run successfully, the data would be "copied directly between the two remote hosts".

Note there is no -i. Should -i ~/keyfile be there? Or rather -i /home/cindy/keyfile or so? (because the local scp got something like this after the local shell expanded the tilde).

No. In general a remote source host may be (and usually is) different than the local host. A path that is valid for the local host may point to anything or nothing on the remote host. If scp on the source host was invoked with -i, it would cause more problems than it could solve. It's a good thing -i does not propagate to the command invoked on the source host. But then the host connects to the destination using its default key or whatever its configuration tells it to use.

In your case it appears one needs the local ~/keyfile to connect to the destination host. The source host holds the right file (because in this particular case the local and the source are the same machine), but the scp command that actually connects to the destination lacks -i (as it should in general) and therefore the key is not used.

Your second command used a local path as a source, only the destination was remote. In this case the key specified with -i was used to connect from the local host to the destination host, exactly as you planned. Therefore it worked.

Note if you configured the local machine to automatically use ~/keyfile to connect to the other server (IdentityFile in ~/.ssh/config), then the first command would work. The local host would unnecessarily connect to itself, only to tell itself to connect to the destination, but still it would work. The first connection would use ~/keyfile because of -i, the second connection would use ~/keyfile because of the configuration.

1
  • SSH agent forwarding could help, right? For example, if you don't want to leave your keyfile on 100.100.100.1 in order to connect to 100.100.100.2, while still being able to scp files between both servers directly. Sep 20, 2020 at 15:03
2

From scp manual, -3 option description: Copies between two remote hosts are transferred through the local host. Without this option the data is copied directly between the two remote hosts. Note that this option disables the progress meter and selects batch mode for the second host, since scp cannot ask for passwords or passphrases for both hosts.

According to description first fails because 2 remote server will communicate directly (in real 100.100.100.1 server will communicate with 100.100.100.2 server via ssh) therefore you have to options:

  1. Use -3 option.
  2. Configure 2 remote servers to be able to authenticate with keyfile ssh key. If you can login from 100.100.100.1 to 100.100.100.2 server with ssh key your original command will work.
4
  • Thanks, but as I wrote " I can freely SSH to either of them from a local machine". I am aware of the -3 option but that is not an option for me for performance issues. But in light of your answer, why does my second command work? Sep 19, 2020 at 14:05
  • My answer gives the same diagnosis, it was under construction when you posted. I decided to publish it anyway because it's less terse. It appears the OP is not convinced, maybe my answer will help then. +1 for you anyway, because you were first and on the right track. Sep 19, 2020 at 14:20
  • @CindyAlmighty you have to SSH from one server to another one (because they will communicate directly not via local machine), not from local machine.
    – GuBo
    Sep 19, 2020 at 14:40
  • @KamilMaciorowski you are correct, your answer did help, but I don't agree that this answer is "the same diagnosis". The -3 segment is confusing in both of your answers and drags away from the main point, and the second point is imprecise. Sep 19, 2020 at 14:58

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.