SSH daemon questions

Matt McCutchen hashproduct+rsync at gmail.com
Mon Oct 15 12:46:32 GMT 2007


On 10/13/07, Alan Cheers <cheersa at brunswickcc.edu> wrote:
> If you had multiple people making rsync backups over ssh wouldn't it be preferred to use the single-use daemons from a security standpoint?  If multiple people use this method I would want to limit the chance of somebody being able to grab or overwrite somebody else's data.  Which do you think is better for a multiuser setup?

If the users have full shell accounts on the destination system (or
you are willing to give them accounts), then each user can push
backups to his/her own account over ssh and can't access anyone else's
backups.  A single-use daemon could optionally be used for the
convenience of having the backups rotated automatically but would not
be involved in the security model.

If the users do not have shell accounts, then the daemon becomes
important as a gatekeeper.  The easiest setup would use a background
(opposite of single-use) daemon with one module for each user.  A user
would authenticate to the daemon using a username/password configured
in the daemon's secrets file and could then access only his/her own
module according to the "auth users" setting in the rsyncd.conf.

Note that the daemon protocol provides neither encryption nor
integrity-checking for the connection, so if there is the potential
for untrusted people to tap the connection, you should protect it
somehow.  One relatively easy way is to convert the daemon to a
single-use daemon over ssh, create an authorized key that has a forced
command that invokes the single-use daemon, and publish the authorized
key for everyone to use.  This way, any user can log in through ssh
and know they have a secure connection to the daemon, but then he/she
must authenticate to the daemon to gain access to modules.

Note: If you intend to deploy rsync for a specific purpose (rather
than just learn about it), it would help if you gave me the entire
picture now instead of revealing it piece by piece.  Let's bring this
conversation onto the list in case the information is useful to others
in the future.

Matt


More information about the rsync mailing list