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.

3 Answers 3


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

  • 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.
    – khosrow
    May 26, 2009 at 1:13
  • 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.
    – khosrow
    May 26, 2009 at 1:50
  • 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).
    – khosrow
    May 26, 2009 at 2:45
  • 1
    rsync -az server:/path /path/on/client ? May 26, 2009 at 2:50
  • 1
    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. May 26, 2009 at 10:10

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/

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .