Hello, I found this page while searching to make rsync over ssl. I found it more interessant to implement TLS on rsync to be able to use the "host" directive in rsyncd.conf (with stunnel rsyncd always sees 127.0.0.1). I'd like to know if you will implement this type of features or not. Thanks Miro
There is a diff in the patches directory named openssl-support.diff that contains an implementation of optional ssl support for an rsync daemon. The version of this patch that was released with 2.6.3 has a few problems, so if you want to try it out, grab the latest version of the patch from CVS: http://rsync.samba.org/ftp/unpacked/rsync/patches/openssl-support.diff I have never gotten the patch to work, however -- it always fails with an "ssl handshake failure". This might be because I don't know the proper way to configure the key/certificate options. Or, it might mean that a bug crept into the code. Perhaps someone should try to contact Casey Marshall (the original author) and ask for some docs.
(In reply to comment #1) > There is a diff in the patches directory named openssl-support.diff that > contains an implementation of optional ssl support for an rsync daemon. The > version of this patch that was released with 2.6.3 has a few problems, so if you > want to try it out, grab the latest version of the patch from CVS: > > http://rsync.samba.org/ftp/unpacked/rsync/patches/openssl-support.diff > > I have never gotten the patch to work, however -- it always fails with an "ssl > handshake failure". This might be because I don't know the proper way to > configure the key/certificate options. Or, it might mean that a bug crept into > the code. The current version of the patch listed above does not run init_tls() in daemon mode. This will of course case start_tls() to fail very quickly which give the above error message. Not sure if that was the problem back in 2004, but with a little tweeking to call init_tls() along with a couple minor things this works for me. My current version of the patch, based on release 2.6.8 is available here: http://staff.osuosl.org/~marineam/files/rsync/rsync-openssl-1.diff I have not extensivly tested things yet, but doing the following gets me a directory listing over the encrypted connection: (using the testing cert/key shipped with stunnel to avoid generating one) rsync --daemon --config ./rsyncd.conf \ --ssl-cert ./stunnel.crt --ssl-key ./stunnel-key rsync --ssl localhost::something/ If anyone has any comments on how to improve the patch let me know, I have not dug into it any further than the minimum required to make it work.
wouldn`t it be better to give up on that effort and recommend stunnel for ssl/tls with rsync ? http://www.stunnel.org/examples/rsync_mike.html
stunnel is usable but it is rather annoying to use for something like pulling backups over rsync using something like dirvish. In that case every host being backed up will have rsync and stunnel daemons running which is simple, but then the backup job has to wrap the rsync command with extra goo to start and stop a stunnel client. So doable but if rsync just supported tls everything would be much friendlier.
Simply using rsync over ssh should be enough encryption for most purposes, IMHO.
when using rsync over ssh, you give a remote user interactive shell access. shell access is not needed for that and may quite often impose a severe security risk. (undermine firewall policies etc) how do you prevent that ? there may be some way to use a restricted shell like scponly, but all such solutions are just an ugly hack, as they are adressing an architectural problem. furthermore , you cannot use ssh for encryption when running rsync in daemon mode. so, the demand for "sending/receiving data trough an encrypted socket connection" is valid, and thus the request for tls here.
It's easy to tell an ssh server to restrict what commands can be run. For example, with OpenSSH it goes in $HOME/.ssh/authorized_keys. That's what I do for making backups: I allow an ssh root login, restricted just to the rsync command needed for making a backup.
authorized_keys command limits sadly only work for public key auth. TLS support in rsync would be of significant value. Yes, there are hacky ways to work around it today, but they all have significant issues in many circumstances.
> It's easy to tell an ssh server to restrict what commands can be run. is that really secure? i think, no. found this one on the scponly pages: SECURITY PROBLEM 2, reported by Pekka Pessi If ANY the following conditions are true, administrators using scponly-4.1 or older may be at risk of remote scponly users circumventing the restricted shell and executing arbitrary programs. There is no privilege escalation and this vulnerability is post-authentication. * scp compatibility is enabled * rsync compatibility is enabled Exploit: To exploit this vulnerability, a remote scponly user could: * construct a malicious command line argument to either the rsync or scp. Athough scponly does check for arguments that allow the user to specify a program to run, it does not use getopt() style processing to locate these potentially malicious arguments. For example, the potentially malicious scp argument "-S program" would be detected but by combining it with the benevolent "-v" (yielding "-vS program") would not. Fix: The new release of scponly-4.2 has: * getopt to process the arguments to scp and rsync. * no support rsync or scp by default. henceforth, the recommended means to use scponly is via sftp * other fixes and features * fix for openbsd ldd in setup_chroot * sftp-logging compatibility patch * fix for autoconf AC_INIT macro * patch for command line args to setup_chroot invocation * patches to fix passw here is some more interesting article which shows, that this is sorta hackerish method: http://www.oreillynet.com/linux/blog/2006/05/restricting_rsync_over_ssh.html
> > It's easy to tell an ssh server to restrict what commands can be run. > is that really secure? i think, no. Yes, assuming you trust rsync itself. For backups, don't use scponly, the grossly insecure script at the end of the oreillynet link, or anything else which gives the client much flexibility. Limit the ssh environment, and in the fixed command script, verify the command it's asked to run is exactly the one it's allowed to run, no dubious "parsing".
from the rsync 3.1.0 release notes : Rsync now comes packaged with an rsync-ssl helper script that can be used to contact a remote rsync daemon using a piped-stunnel command. It also includes an stunnel config file to run the server side to support ssl daemon connections. See the packaging/lsb/rsync.spec file for one way to package the resulting files. (Suggestions for how to make this even easier to install & use are welcomed.)
based on http://dozzie.jarowit.net/trac/wiki/RsyncSSL
As roland points out, there is now an ssl solve provided with rsync, and it supports the host directive because rsync pays attention to the environment variable that stunnel sets which tells rsync what the originating IP is for the connection.