Re: Setting permissions of ssh access

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

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.

Iphone says hello.