copying files over multiple ssh tunnels

Question

I have an awkward situation in which I need to link to a machine through multiple tunnels. Details why below, but this command works for sshing in to server2:

ssh -A -t [email protected] ssh -A -t [email protected] ssh -A -t [email protected] ssh -A [email protected]

(for brevity, that command is now $ssh_cmd) How can I copy files to/from that machine using a similar tunnel setup? I have tried, for example:

rsync --rsh=ssh -e "$ssh_cmd" [email protected]:filename .

which, even after removing the -t, fails because it doesn't give me an opportunity to enter my password:

debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.

So how can I set up this tunneling copy command?

extra details:

• portal1 blocks proxy commands, which necessitates one extra of these jumps and prevents convenient .ssh/config hackery
• the failed authentications seem to have gotten me blocked at least once

EDIT: larsks suggested using key-based authentication, which worked to a point, then failed with:

debug1: Host 'server2.host2.org' is known and matches the ECDSA host key.
debug1: Found key in /home/username2/.ssh/known_hosts:3
debug1: read_passphrase: can't open /dev/tty: No such device or address
Host key verification failed.

which I don't understand; if it found the key why didn't it use it?

Answer 1

The answer is, at least in part, that my rsync command was wrong. The ssh command above should have excluded the last reference to the username/host, i.e.:

ssh -A -t [email protected] ssh -A -t [email protected] ssh -A -t [email protected] ssh -A

instead of the command shown above. This became evident in the debug output:

debug1: Sending command: ssh -Av [email protected] -l username2 server2.host2.org rsync --server --sender -vvulogDtprCe.iLs . filename
bash: server2.host2.org: command not found

where it is redundantly specifying the server, such that the server name was being interpreted as a command remotely.

For the authentication failure, using key-based authentication solved the problem.

I also added -o StrictHostKeyChecking=no to deal with the host key validation failure.