# rsync over ssh: keep file ownership using non-root account

## nielchiano

Hi,

I do my backups using rsync over ssh. this works great: backups are preformed quickly with only the changed things. I run rsync localy as root, so I have access to all files, and connect to the remote computer using ssh with RSA-keys using a "backup" account (i.e. non-root).

Backups work great this way, but I can't backup the file-ownerships, since a regular user can't do that.

What are possible solutions for this?

I don't want to connect to root@remote, because that would mean when one machine get's compromised, the other is too (since the logins happen automaticaly with RSA-keys). Right now the only are able to read/write on the backup partition, which is already bad enough.

Can I give the backup-user enough privileges to do the chown's? how?

----------

## ansient

You could user tar, e.g.

```
tar cvjpf backup.tar.bz2 <stuff to backup>
```

----------

## nielchiano

 *ansient wrote:*   

> You could user tar

 

I did use tar before, but it was too slow and took up a lot of space... I have to backup around 30GB, but only about 10MB get's changed between the backups.

Also, extracting a 6GB-tar to find one specific file takes a while...

So good option, but not applicable to me

edit: yes, I also tried incremental backups, so don't mention it

----------

## nielchiano

bump

----------

## ansient

The correct solution is to not use a backup user.

----------

## nielchiano

 *ansient wrote:*   

> The correct solution is to not use a backup user.

 

and expose the root account??

----------

## ansient

 *nielchiano wrote:*   

>  *ansient wrote:*   The correct solution is to not use a backup user. and expose the root account??

 rsync over ssh is secure.

----------

## nielchiano

 *ansient wrote:*   

>  *nielchiano wrote:*    *ansient wrote:*   The correct solution is to not use a backup user. and expose the root account?? rsync over ssh is secure.

 That's not the point, this is:

 *Quote:*   

> I don't want to connect to root@remote, because that would mean when one machine get's compromised, the other is too (since the logins happen automaticaly with RSA-keys).

 

----------

## ansient

You're doing things the wrong way.  The rsync should run as root, AT THE BACKUP SERVER.

If you don't want it to connect as root to the machines to be backed up, then you can use any user that has read-only access to the files.

----------

## nielchiano

 *ansient wrote:*   

> If you don't want it to connect as root to the machines to be backed up, then you can use any user that has read-only access to the files.

 

And how do I create sush user? the data to be backed up is user-data with unknown permissions

----------

## ansient

 *nielchiano wrote:*   

>  *ansient wrote:*   If you don't want it to connect as root to the machines to be backed up, then you can use any user that has read-only access to the files. 
> 
> And how do I create sush user? the data to be backed up is user-data with unknown permissions

 

*sigh.. you can't put the data somewhere readable by the backup user?

Heck if your requirements are this complicated, set up a chroot on the backup server and go nuts.

Then someone getting access to the chroot will be no different then it would be for them to have access to the backup user.

----------

## joaander

How about this: creat the permissions preserving tarball and rsync that file.

Think it wont work? Well, you are right. Unless you use the --rsyncable option to gzip. Some good information here: http://glasnost.beeznest.org/articles/206 and lots more available via google.

And the best part is, the patch is used in the gentoo ebuilds :) (using the gzip-1.3.5-r7 here)

```
$ gzip --help

gzip 1.3.5

(2002-09-30)

usage: gzip [-cdfhlLnNrtvV19] [-S suffix] [file ...]

    <snip>

    --rsyncable   Make rsync-friendly archive

 file...          files to (de)compress. If none given, use standard input.

```

----------

## nielchiano

 *joaander wrote:*   

> How about this: creat the permissions preserving tarball and rsync that file.

 

hmm... didn't know that...

but this issue still remains (i know, I'm being difficult...)

 *Quote:*   

> Also, extracting a 6GB-tar to find one specific file takes a while...

 

Another issue is that currently I keep 40 backups around, which are hardlinked to eachother, so hardly take space; an advantage I loose with tar

----------

## joaander

Then I would agree with ansient, it seems the only way to get exactly what you want is to run a chrooted rsync server on the backup host. You could firewall the rsync port and then connect via a ssh tunnel. This fits your security requirement that if one system is compromised, the only passwordless login available is the backup user on the other host. And via the chrooted rsync daemon running as root, the only files compromised with root access are the backup files. 

It shouldn't be any more difficult to setup than what you have now. IIRC, the example rsync.conf that is installed shows how to setup a chrooted rsync daemon and even strongly advises against disabling the chroot.

----------

## nielchiano

I finally got around to try this... (shame on me)

But I still have a problem.

Asume the following config:

server runs backup-script as root on crontab

connects to backup using keyed-ssh an backup user (non-root); sets up a ssh-tunnel to backup's rsync-daemon (running as root).

This will work as I want it.

The thing that is still bothering me: how do I delete old backups this way? Since the files in the old snapshot are owned by their owner, the backup-user can't delete them...

----------

