secure remote backups

[mike wolman]

>
> 1.  If someone compromises root@backup_server, apparently it is now
>     easy for them to log into machine.to.backup as mike, and delete
>     all of mike's files.  (But perhaps it was this way before
>     rdiff-backup.)

When i run rdiff-backup with the following remote schema:
--remote-schema "ssh -C %s '/home/backupuser/backup.sh'" \

I am prompted for a password, i do not plan to run this via a cron job
so will actually be there to enter the password - i am planning on using
ssh keys (with passphrase). Would this then not be the same risk
as allowing user mike ssh access?

>
> 2.  If someone compromises root@backup_server, they can run the
>     rdiff-backup server as root@machine.to.backup, and get it to
>     read/erase arbitrary files on machine.to.backup.
>
> 3.  If someone compromises mike@machine.to.backup, they can also run
>     the rdiff-backup server as root@machine.to.backup, and if they
>     know what they are doing, they can get root access on that
>     machine.
>
> 4.  If someone compromises root@machine.to.backup, they can rewrite
>     the rdiff-backup server there, and try to hack the client (running
>     as root@backup_server when it connects) to get root access at
>     backup_server.
>
>

I should run Aide or tripwire check before each backup to ensure
the machines being backuped have not been comprimised.
My main concern is 4. and the main backup server being comprimised,
i presume chrooting rdiff-backup to each machines backup directory
wont be possible.

Most of the machines being backed up are sitting behind firewalls and i am
filtering out all ssh incomming traffic execpt from the backup server -
they're mainly smb hosts.

Mike.