Rather PUSH backups. This way you can 1) Close the backup machine to allow ONLY access from the specified machines on an IP/MAC bases (since it's local net) 2) You don't have to open up root access for any machines 3) You can have the rsync client run as root to allow it to copy all files on it's own machine, then copying it to a lower access user on the target machine. If you want your backup files to be stored with the same ownership/permissions as on the source machine, you would have to login as root on the backup machine. If it's closed from outside access this is safer than allowing root access to your public machine. Further restricting it by IP/MAC makes this even more secure. If using something like rsync-backup, you're basically running a static command on the backup server's side, which provides an extra level of security if you want to have the backup server side execute as root as well. Let me explain it like this: 1) You have the source machine S - it's public 2) You have the machine machine B - it's completely closed up and only allows IP/MAC level filtering on incoming port 22 from machine S 3) On machine B you have a root account with a password for you to login 4) You want machine S to use this root account to copy it's backups 5) You use rsync-backup wrapped in ssh to do this. This means you have 2 commands run by ssh, the rsync-backup client command and rsync-backup server side command 6) You setup a public key on the root account on machine B, which is only allowed to run a single command, the rsync-backup command. This means rsync-backup authenticates using the public key, but is only allowed to run a fixed command, which is the one it uses to copy the backups. So it is authenticated as root, which allows you to copy all types of ownership/permissions, even setuid bits, but you can't do ANY other than what rsync-backup command and it's protocol allows. Have you heard of rsync-backup? It's a utility which uses rsync's libraries, but provides common backup features like exclusions, incremental backups + increment management, etc. The technique listed above is what I use to make all my backups. It's really simple, works brilliantly and with the specified would be very secure as well. Since it's running as root there is always the risk of exploitation to gain root access, which could cause compromise of your other machines, though it's already very secure and always possible to add extra levels of security. Quintin Beukes On Fri, Oct 23, 2009 at 9:28 PM, Scott Haneda <talklists@xxxxxxxxxx> wrote: > Hello, I've looked around and found a few different approaches to this. > Looking for a discussion of the pros, cons, and best practices. > > I want to use rsync over an ssh connection to clone one machine to another. > This means one end will need root login. > > Right now I have passwordless keys to allow myself to login. Root login is > disabled. > > Would an acceptable method be to allow root login from a specific IP > address? Or is there some other way to allow root privilege use between a > source and destination host without opening it up by IP? > > This is for backups, and only ever will be machine to machine, same subnet. > I'm not immediately seeing how to set granular permissions based on > conditions like IP, MAC, or other harder to spoof credentials. > > I'd it better to pull backups or push backups, or equivalent? > > The backup machine could be made to have no public access at all. Thanks for > any pointers. > > -- > Scott > Iphone says hello. >
