Both full and incremental backups seem to be working. I am using the checksum thing.
Below is about where things stand now (on the client machine). ---------SNIP-------------- root@newmain2:/var/lib# ls -ld backuppc/ dr-xr-x--- 4 backuppc1 backuppc 4096 Feb 4 15:38 backuppc/ root@newmain2:/var/lib# ls -la backuppc/ -r-xr-x--- 1 backuppc1 backuppc 75 Feb 4 13:15 .onlyrc -r-xr-x--- 1 backuppc1 backuppc 403 Feb 4 13:43 .onlyrules dr-xr-x--- 2 backuppc1 backuppc 4096 Feb 5 08:03 .ssh drwxr-x--- 2 backuppc1 backuppc 4096 Jan 24 12:06 log root@newmain2:/var/lib# ls -la backuppc/.ssh -r-xr--r-- 1 backuppc1 backuppc 210 Feb 3 18:12 authorized_keys -rw-r--r-- 1 backuppc1 backuppc 0 Feb 5 08:03 known_hosts In terms of what file gets visited first, that would be the .ssh/authorized_keys file. command="only /usr/bin/sudo",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-ed25519 AAAAAA... backup...@example.com I edited part of the content. But that is all one line. I believe I could also add from="example.com" to the beginning of that line, to further restrict the use of this key. The command being run is "only" with an argument of /usr/bin/sudo. Only is installed in /usr/local/bin. There is no Debian package for only. The reference for "only" is http://at.magma-soft.at/sw/blog/posts/The_Only_Way_For_SSH_Forced_Commands/ Only can make use of two other files. The .onlyrc file just has comments in it, it could easily be empty. The .onlyrules file contains: \:^/usr/bin/sudo /usr/bin/rsync --server --sender --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --recursive --checksum-seed=32761 --ignore-times . /:{p;q} \:^/usr/bin/sudo /usr/bin/rsync --server --sender --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --recursive --checksum-seed=32761 . /:{p;q} These are sed patterns. The first pattern matches the rsync command being used to do a full backup, and the second matches the rsync command being used to do an incremental backup. The only difference is the --ignore-times. If the command coming in matches a pattern (and I only have 2 listed), that line is "printed", If no line matches, nothing is "printed". The first match, is the one which triggers the "print", so that patterns from go from most specific to least specific. As I have not looked at doing restores (yet), I am missing any rsync commands related to those. In any event, sudo (as the user backuppc1) is looking to run rsync. root@newmain2:/var/lib# cat /etc/sudoers.d/backuppc backuppc1 newmain2=(root) NOPASSWD:/usr/bin/rsync So sudoers.d/backuppc is letting backuppc1 run rsync as root, with no password. The permissions on ~/, ~/.ssh and ~/.ssh/authorized_keys are tighter than most people use, as I've removed write permission for backuppc1 in their home directory, in the .ssh directory and for the authorized_keys file. This is probably just an annoyance for someone skilled at breaking in, but it should stop accidental clumsyness from causing problems. I could have set the immutable attribute on some things, which might make it more difficult to cause problems. But I think that having the rsync process running as root probably gives them all the abilities they need to get past a bunch of security, should they desire to do so. Maybe AppArmor or SELinux could mitigate against some of those problems? I know very little about them. Gord _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
