Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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 oracle@database.com > 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.

share|improve this question

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

share|improve this answer
    
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 May 26 '09 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. –  Xerxes May 26 '09 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). –  Xerxes May 26 '09 at 2:45
1  
rsync -az server:/path /path/on/client ? –  Dave Cheney May 26 '09 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. –  Paul de Vrieze May 26 '09 at 10:10
up vote 2 down vote accepted

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/
share|improve this answer

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

http://serverfault.com/questions/6367/cant-get-rsync-to-work-in-daemon-over-ssh-mode

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.