On Thu, 2005-10-20 at 01:15 +0100, Manuel López-Ibáñez wrote:
> [...] There is a FAQ section (which I linked in my first message) explaining
> how to do this using keys. That is not the point. For example, isn't it
> possible for the root of middle (or some attacker) to get my keys and
> use them?


Yes, root of middle can cause you a lot of trouble. Not only can root
intercept the password going to the second SSH; root can surreptitiously
modify the rsync data going back and forth! Now I get the picture: you
don't trust middle and would want nothing to do with it except that it
is the only way your data can reach target. There's a technique that
can deal with this situation very elegantly: forward target's SSH port
itself to your machine. Here's the general procedure:

Terminal 1:
$ ssh -L 2222:target:22 -N -f middleuser@middle
Password: middlepass


Terminal 2:
$ ssh -P 2222 targetuser@localhost
Password: targetpass


Terminal 1:
^C to kill the forwarding ssh

If you use this setup, then middle can do nothing more to you than a
random node on the Internet could. Authentication and data transfer
appear to take place directly between your machine and target; all rsync
and SSH-authentication data is securely encrypted when it passes through
middle. This is really great. The only drawback is that any process on
your machine can piggyback on your forwarding and make its own SSH
connection to target; decide whether you want to worry about this.

Since the second SSH thinks you're connecting to localhost but sees
target's host key, you're going to get dire warnings about host keys.
By editing your SSH configuration file (~/.ssh/config), you can both
solve the host key problem and make the procedure more automatic. Try a
configuration file like this:

Host middle
LocalForward 2222 target:22
User middleuser

Host target
HostName localhost
HostKeyAlias target
Port 2222
User targetuser

Then, say "ssh -N middle" in one terminal, supply the password, and let
ssh run. In another terminal, run rsync without any -e option. It will
call "ssh target", which will know from the configuration file to
actually go to localhost:2222 but to expect target's host key and will
Do The Right Thing.

I tried this technique, using a configuration file like the one above,
and successfully accessed one of my school's machines via forwarded SSH.
Good luck! I'm hoping this will prove to be the solution!
--
Matt McCutchen, ``hashproduct''
hashproduct@verizon.net -- http://mysite.verizon.net/hashproduct/

--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html