Aw: Re: encrypted rsyncd - why was it never implemented?

[devzero at web.de]

from a security perspective this is bad. think of a backup provider who wants to make rsyncd modules available to the end users so they can push backups to the server. do you think that such server is secure if all users are allowed to open up an ssh shell to secure their rsync transfer ?

ok, you can restrict the ssh connection, but you open up a hole and you need to think twice to make it secure - leaving room for hacking and circumventing ssh restrictions.

indeed, rsyncd with ssl is quite attractive, but adding ssl to rsync adds quite some complexity and also increases maintenance work.

for some time there is a ssl patch in the contrib directory, but  i`m curious why nobody is aware of rsyncssl, which is not a perfect but quite some elegant solution to support wrapping rsyncd with ssl via stunnel:

http://dozzie.jarowit.net/trac/wiki/RsyncSSL
https://git.samba.org/?p=rsync.git;a=commit;h=70d4a945f7d1ab1aca2c3ca8535240fad4bdf06b

regards
roland



> Gesendet: Mittwoch, 03. Dezember 2014 um 19:19 Uhr
> Von: "Kevin Korb" <kmk at sanitarium.net>
> An: rsync at lists.samba.org
> Betreff: Re: encrypted rsyncd - why was it never implemented?
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> You can run rsyncd over ssh as well.  Either with -e ssh host::module
> or you can use ssh's -L to tunnel the rsyncd port.  The difference is
> which user ends up running the rsyncd.
> 
> On 12/03/2014 12:40 PM, Tomasz Chmielewski wrote:
> > rsync in daemon mode is very powerful, yet it comes with one big 
> > disadvantage: data is sent in plain.
> > 
> > The workarounds are not really satisfying:
> > 
> > 
> > - use VPN - one needs to set up an extra service, not always
> > possible
> > 
> > - use stunnel - as above
> > 
> > - use SSH - is not as powerful as in daemon mode (i.e. read only
> > access, chroot, easy way of adding/modifying users and modules
> > etc.)
> > 
> > 
> > Why was encrypted communication in rsyncd never implemented? Some 
> > technical disagreements? Nobody volunteered?
> > 
> > 
> 
> - -- 
> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
> 	Kevin Korb			Phone:    (407) 252-6853
> 	Systems Administrator		Internet:
> 	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
> 	Orlando, Florida		kmk at sanitarium.net (personal)
> 	Web page:			http://www.sanitarium.net/
> 	PGP public key available on web site.
> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iEYEARECAAYFAlR/VEUACgkQVKC1jlbQAQcE+wCfYD+irslnu/nRool4RPL+KjUC
> J9wAoKmYNAlfpCMlVKYcV+jpW8e0YNF6
> =oUk3
> -----END PGP SIGNATURE-----
> -- 
> Please use reply-all for most replies to avoid omitting the mailing list.
> To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
>