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

[Kevin Korb]

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

First off, this isn't "restricted shell".  Second, the user's shell
can also match the forced command so that no shell (especially bash)
is involved.

On 12/03/2014 03:09 PM, devzero at web.de wrote:
>> The benefit of rsync over ssh secured by rrsync is that it is
>> more like what rsync users are already used to.
> 
> i don`t like rsync over ssh in an environemt with users you can´t
> trust.
> 
> from a security perspective, i think such setup is broken by
> design.
> 
> it`s a little bit like giving a foreigner the key to your front
> door and then hope that the door in the corridor to your room will
> be "secure and stable enough".
> 
> some reasons why i think this way can be found here: 
> https://www.google.de/search?q=ssh+restricted+shell+bypass
> 
> regards roland
> 
> 
> 
>> Gesendet: Mittwoch, 03. Dezember 2014 um 20:37 Uhr Von: "Kevin
>> Korb" <kmk at sanitarium.net> An: devzero at web.de Cc:
>> rsync at lists.samba.org Betreff: Re: Aw: Re: encrypted rsyncd - why
>> was it never implemented?
>> 
> 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/dNsACgkQVKC1jlbQAQfCxQCfQw1JOXL4aF9MrU2EFznwEjUl
WkgAn0F4QkgrM7M2KA03PeDdUFuNLY4Q
=oEpE
-----END PGP SIGNATURE-----