Encrypted automated backups

[grant123]

I have three systems in three locations. Two of the systems contain important data that needs to be backed up and those systems should be kept as secure as possible. I was thinking the two important systems could rsync push to the unimportant system and then rsync pull each other's data from there. That way the only accessible system is the unimportant system.

I'd like to incorporate encryption for the backups but how can that encryption be both secure and automated?

[Hu]

I assume you mean you want the backup data to be encrypted at rest, since using rsync over ssh solves the problem of having the data encrypted in transit. Unfortunately, mixing encryption with rsync is difficult, since you want to rsync the encrypted form, and the good encryption techniques do not regenerate the same ciphertext for a given plaintext. If you can give up rsync, you could use tar, possibly in incremental mode, to create an archive, encrypt the archive, and then copy that to the destination. You could then use gnupg in key mode to encrypt the archive with a public key, where the private key is kept offline and accessible only to the backup administrator.

[grant123]

Ouch. It sounds like I may be out of luck. I do want to use rsync so I don't have to transfer so much data. I'll have to rethink this.

[Hu]

Unless you were planning on using the rsync capability to send only the changed blocks within a file, as opposed to running it with --whole-file, an incremental tar will not be substantially different from using rsync.

[vaxbrat]

Use ssh-keygen to generate a public/private keypair for whatever user you want to use to transfer files. Just hit a return when prompted for an optional passphrase. Copy the ~/.ssh/id_rsa.pub to the destination host and user's ~/.ssh/authorized_keys file. If you want to manage more than one key then just append to that file.

At this point you can do an ssh or scp from the source to the destination host without a login prompt and could thus then use these commands in a script or from a crontab.

You could even use root to do this, but realize that it is a potential problem for network-wide pwnage. The private key (~/.ssh/id_rsa file) on the source machine must be treated as a security relevant object.

If you have a policy to change passwords on a scheduled basis, you will also want to do a keyroll of the authorized keys by using ssh-keygen to generate a new pair as necessary and to then update the authorized_keys files.

[Hu]

To further secure the process, you could restrict the automated ssh key to use only sftp and/or be in a chroot on the receiving system. This would restrict a compromised key to the ability to manipulate only the approved directories, so it could delete older backups, upload false new ones, or exhaust disk quota, but not run a shell or directly read non-backup-related files. If you follow my earlier comment and transfer encrypted tar files, then there is no need for the receiving system to allow the key to log in as root.

[grant123]

I think the key factor is that the incrementation and encryption is done on the source system before anything is transferred to the destination. How about duplicity for this? It sounds like the right tool for the job: