rsync through ssh proxy using a key that is on the proxy

Question

I am trying to copy files using rsync from a server A, to a server C, through a bastion server B.

A -> B -> C

This can be achieved normally through using the -e option, like: rsync -e 'ssh user@host' .... However, I can't figure out or find examples on how to do this when the server B has the key that server C is expecting. All search results assume server A has the key, and that key is on both B and C.

I can successfully use this ssh command to use the remote key:

ssh -t user@hostB ssh -i /home/user/.ssh/private_key user@hostC

But I am not able to translate this into a valid rsynd -e '...' command. One main issue is that the above changes the ssh startup shell using -t, which I don't think is the correct approach. I've also tried using the JumpHost ssh option:

rsync -e 'ssh -J user@hostB' ...

This is also unsuccessful.

While using rsync is preferred, if this isn't possible then a solution that uses scp will also be acceptable.

Answer 1

Solution

When you use rsync -e ssh local_path userX@serverX:remote_path, rsync takes the option-argument of -e (here ssh) and adds userX@serverX and more to build the command it will use. In effect the command will be like:

ssh userX@serverX …

where … denotes rsync-specific command to be run on the remote side.

You want the command to be:

ssh user@hostB ssh -i /home/user/.ssh/private_key user@hostC …

so your rsync command needs to be:

rsync -e 'ssh user@hostB ssh -i /home/user/.ssh/private_key' local_path user@hostC:remote_path

---

Additional explanation

You must not use ssh -t. The command that worked for you:

ssh -t user@hostB ssh -i /home/user/.ssh/private_key user@hostC

spawns an interactive shell which works well when there is a tty allocated on hostB and on hostC. ssh won't allocate a tty on the remote side automatically if you specify a command; otherwise it will. In the above command the outer ssh runs a command (ssh -i …) and it wouldn't allocate a tty on hostB, if you didn't use -t. The inner ssh sees no command, so it allocates a tty on hostC automatically before running a shell there.

An interactive shell needs a tty. It's different with rsync, it needs a raw data channel; changes and translations imposed by tty will break things. That's why you mustn't use -t at all. Then each ssh will see some command specified (in case of the inner ssh it will be the command added by rsync), so there will be no tty allocated on hostB and no tty allocated on hostC.

Why -J is not a solution is explained at the beginning of this answer.

Answer 2

After researching further, this looks like it is an insecure process. Instead, I think the correct solution is to add the key on server A to both server B and C as authorized keys. After that, this solution should be used: https://superuser.com/a/1115998/1621610