< Day Day Up > |
Recipe 16.5. Securing rsync Modules16.5.1 ProblemYou followed Recipe 16.4, and you really like giving users the power to fetch their own files from the backup server, or delegating updates of web and FTP servers to someone else. But it's wide open to anyone using rsync—how do you secure the modules? 16.5.2 Solutionrsync comes with its own simple authentication and access controls. You'll create a new file containing username/password pairs, and add "auth users" and "secrets file" directives to /etc/rsyncd.conf. First create the password file on the rsync server. This example is for our fearless user, Sue. Make it chmod 600: # rsync-users for server1 # created 2/7/2004 sue:sekkrit Next, edit /etc/rsyncd.conf. Give Sue her own module, and lock out everyone but her: # global settings log file = /var/log/rsyncd.log #modules [sue_backup] path = /backups/sue comment = Sue's private archive list = yes read only = no auth users = sue secrets file = /etc/rsync/rsync-users To access the module, Sue must prefix the server name with her rsync username: sue@workstation:~$ rsync sue@server1::sue_backup Password: drwx------ 192 2003/02/12 spreadsheets -rw-r--r-- 21560 2003/09/17 aug_03 -rw-r--r-- 21560 2003/10/14 sept_03 -rw-r--r-- 21560 2003/11/10 oct_03 Now she can upload and download files just like before, as long as she remembers to use her rsync login. Don't forget the double colons, which are used when connecting to an rsync server. 16.5.3 DiscussionThe username/password pairs are arbitrary and are not related to system user accounts, so it is quick and easy to create or edit modules and add or delete users. For additional security, add these directives to rsyncd.conf:
hosts allow = *.windbag.net hosts allow = 192.168.1. All hosts not allowed are denied, so you don't need a hosts deny directive.
The password file is in cleartext, so it must be restricted to the superuser. 16.5.4 See Also
|
< Day Day Up > |