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

[Kevin Korb]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As far as a backup provider goes I wouldn't expect them to use rsync
over SSL unless that were built into rsync in the future (and has been
around long enough that most users would have it).

I would expect them to either use rsync over ssh secured by rrsync or
rsyncd over ssh with them managing the rsyncd.conf file.  Either way
the server side command would be forced and no other ssh functionality
would be allowed.

The benefit of rsync over ssh secured by rrsync is that it is more
like what rsync users are already used to.

The benefit of rsyncd over ssh would be that the provider would manage
the rsyncd.conf files (1 per user) and could make a web UI to control
certain aspects of it.

I am thinking of something like this with in sshd_config with
whichever ForceCommand they would pick:

Match Group backupusers
  X11Forwarding no
  AllowTcpForwarding no
  ForceCommand /usr/bin/rsync --server --daemon .
  ForceCommand /usr/bin/rrsync-wrapper

Note that a wrapper or modification would be needed for rrsync since
sshd_config doesn't support %u or %h in ForceCommand :(


On 12/03/2014 02:20 PM, devzero at web.de wrote:
> 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?
>> 
> 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?
>>>> 
>>>> 
> 
>> -- 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
>> 

- -- 
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
	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/ZpYACgkQVKC1jlbQAQcv2wCg5VUHdgqm1qCKMjq2jMS+cYnU
nC0AoJ6n/Pi9+CTAp0r5cPtF8V32y5G4
=CtdG
-----END PGP SIGNATURE-----