encrypted rsyncd - why was it never implemented?

[Hendrik Visage]

On Wed, Dec 3, 2014 at 9: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 ?

For a *start* Those users needed to be properly authenticated,
authorized and accounted (AAA) for. In that case, you can't run rsyncd
*without* passwords and usernames etc. I can't recall that those
passwords are encrypted in anyway, as it needed the unencrypted for
the way it send the password's challenges back and forth.

The next fun part in this way, is that you'll need to create a
stanza/entry for each user and their directories, else you'll be
violating the authorization requirements.
It'll be easy for a couple, but what about the hundreds of users?

> 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.

Instead of having that at the rsync level?

Yes, ssh is a piece of software that had it share of security
violations, I'll agree, but it'll be much more manageable AAA (imho
and experience) to have the clients' ssh pub-keys inserted into an
authorized keys file with only the /usr/bin/rsync --server (etc.) as
the command that could be executed, in their own home directory (which
is the backup folder for that user) with only that user having
read-write permission in that folder, and the shell of that account
being /bin/true with a bogus /etc/shadow password string, something
like $6$oops$trythisforsha512 or just the plain old *, and you have a
decent security system in place for the backups, using rsync.

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

Given the above description, I'll ask: Why SSL?
Even better: Which SSL implementation? you don't want the OpenSSL with
all it's troubles, and then GnuTLS also had it's fun of security holes
I recall.


> 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

If that works for you, fine, I just think that ssh does the job well
enough with out having to add undue complexity to rsync

>
> 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
>>
> --
> 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