Bug 1890 - TLS for rsync protocol
TLS for rsync protocol
Status: RESOLVED FIXED
Product: rsync
Classification: Unclassified
Component: core
2.6.3
All Linux
: P3 enhancement
: ---
Assigned To: Wayne Davison
Rsync QA Contact
http://metastatic.org/source/rsync-ss...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-08 11:29 UTC by Miroslaw KLABA
Modified: 2013-11-23 19:02 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Miroslaw KLABA 2004-10-08 11:29:37 UTC
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
Comment 1 Wayne Davison 2004-10-08 14:49:49 UTC
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.
Comment 2 Michael Marineau 2006-08-06 02:39:46 UTC
(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.
Comment 3 roland 2009-08-07 05:11:57 UTC
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

Comment 4 Michael Marineau 2009-08-07 14:52:25 UTC
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. 
Comment 5 Paul Slootman 2009-08-08 06:00:15 UTC
Simply using rsync over ssh should be enough encryption for most purposes, IMHO.
Comment 6 roland 2009-08-08 06:44:14 UTC
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.
Comment 7 Jamie Lokier 2009-08-08 18:16:05 UTC
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.
Comment 8 Carson Gaspar 2009-08-09 00:18:13 UTC
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.
Comment 9 roland 2009-08-09 05:33:36 UTC
> 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
Comment 10 Jamie Lokier 2009-08-09 05:54:20 UTC
> > 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".
Comment 11 roland 2013-11-22 22:21:30 UTC
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.)
Comment 12 roland 2013-11-22 22:22:40 UTC
based on http://dozzie.jarowit.net/trac/wiki/RsyncSSL
Comment 13 Wayne Davison 2013-11-23 19:02:37 UTC
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.