Consolidate & restrict backup procedure over ssh

[zooey]

Baron grants sudoable rsync access to the backup user via ssh. This is used for pull-style filesystem syncs initiated from an external server.

In order to restrict the possible damage should an intruder ever get in possession of the private ssh key granting that access on baron, the process should be reviewed and improved.

Suggestions:

• The authorized_keys file should be adjusted to limit access only to orange.hirschkaefer.de (and any other backup servers that we might want to use)
• The authorized_keys file should be adjusted to specify the exact command to use for the backup process (possibly a shell script residing on baron containing the exact rsync invocation).
• Instead of sudoing rsync directly, the backup process should sudo a shell script owned by root - this way an intruder can't bend the rsync cmdline to copy out interesting files.
• The rotated backups are currently push-style, i.e. they are being pushed from baron onto the external backup server using another ssh key. From a security perspective, having both push- and pull-style backups to/from the same backup server isn't nice, as a successful attacker on baron could use the push-style backup path to gain access to the backup server, too. Would the rotated backups to be pull-style, too, we could close the access path from baron to the backup server.

[zooey]

Actually, the same kind of pull-style backup is being initiated from baron for each VM, too. However, in that case those kind of adjustments won't help much, as any intruder would need to become root on baron to get access to the private ssh key. Root on baron has write access to all VM filesystems, too, so it seems futile to adjust their backup configuration.

[nielx]

The haiku-sysadmin user no longer exists, changing to haiku-web.

[pulkomandy]

I think this ticket refers to a server that does not exist anymore, and can now be closed?