How to perform a secure rsync between servers across an unsecured network

Question

Basically what I'm asking is, has anyone come across a means by which to wrap rsync inside ssh.

With OpenSSH v4.9+ sftp has some nice options that allow you to chroot the incoming connection and such - and that's a solution that I would look at, however I'm stuck with RHEL, and neither RHEL4 or RHEL5 are upto that version of ssh.

My current solution is to add something like this to the server-side using the client user's key...

server% cat ~/.ssh/authorized_keys
command="cd /srv/rsync/etl && tar --exclude './lost+found' -pcf - ./" ssh-rsa...

...and so the client would then be restricted to one thing and one thing only...

client% ssh -T -i ${HOME}/.ssh/id_rsa [email protected] > sensative.tar

This secures the connection, as well as the server (from the client), however is inefficient as all files will be retrieved over and over again.

I'm after doing something similar (or just better) using rsync.

Solution 1

Okay I finally figured this out, but the solution is not as elegant as I had hoped for.

One the server side, you need to add the following to the authorized_keys file for the relevant user...

no-pty, command="exit"

On the client, you can then create a tunnel as follows...

ssh -l username -fNTL 8073:server:873

Once the tunnel is establised, you can rsync as per usual - using the double-colon syntax is not possible - to localhost.

The localhost port number you select (8073) are entirely optional obviously, just remember that that's what you have to rsync to...

rsync --port=8073 -a user@localhost::mySecureStore /srv/some/place/

Solution 2

Rsync supports using ssh as a transport

rsync -az /path/to/source username@host:/path/to/destination

some older versions of rsync require you to specify ssh explicitly

rsync -aze ssh /path/to/source host:/path/to/destination

An alternative to using rsync is B. C. Pierce's Unison, which has similar functionality to rsync, but keeps a local index at both ends to avoid having to walk the filesystem to calculate the deltas

Solution 3

You might be interested in daemon-over-ssh-mode, which is the subject of this question:

Can't get rsync to work in daemon-over-ssh mode

Comments

[Xerxes]

Thankyou for the quick response! I should have mentioned that I investigated that too - the problem (in my case) with that is that it does not restrict/chroot the user. If it was possible to talk to the rsync service via ssh (i.e. using the double-colon syntax of defining the remote) - that would be perfect - but the above only works with single-colon - i.e. via ssh, and hence no chrooting.

[Xerxes]

I forgot to mention - Unison looks nice, and I'll keep a link to it - however in this case - I'm unable to install anything outside of that offered by RHN - which is lame, but out of my control.

[Xerxes]

Yet another restriction I should mention is that the connection needs to be initiated from the client - the <i>pulling</i> side, and not the server. (Server-side push would naturally be easy to secure the server as the client has no say, but not applicable to my current problem).

[Dave Cheney]

rsync -az server:/path /path/on/client ?

[Paul de Vrieze]

Why the chroot? You do know that a chroot does not really improve security that much. Further, if you already go out providing ssh then rsync over ssh does not reduce the safety of the system. Also think about it that what rsync over ssh does is invoke the rsync binary on the server. You can secure that the same way you secure your copy command.

[Xerxes]

I have to disagree, although I used the term chroot lightly With the rsync protocol - you offer a specific location for a specific user to access, they do not get shell access. With ssh, unless specified via the authorized_keys file, the user has shell access. Similarly with sftp prior to v4.9, they are again free to roam the filesystem. I'm sorry if I was somehow vague in my description of the problem =).