*Recent amanda-user discussion on encryption*

Different encryption configuration

Transport Data Tag
no no A
yes no B
no yes C
yes yes D [separate encryption, back to clear on server]
yes still E [client encrypts, server passthrough]

In scenarios A and C, and eavesdropper on the network can observe the data. In B D and E an eavesdropper cannot.

In secenarios A and B, one can retrieve the data from backup tapes without keying material. This is perhaps obvious, but very important for backups.

In C, D, and E, the backup tapes are encrypted. Thus, one could store them someplace where you trust people not to destroy them but you don't trust them to read them. This can make some sense for particularly sensitive data.

In E, the backup data doesn't appear on the server in plaintext. This can be useful for backing up clients with particularly sensitive data. To really make sense, the client should be configured so that it will only honor dump requests to a preconfigured set of public keys.

SSH

ssh provides transport encryption and authentication. The only caveat is that the amanda binary needs to be installed at the same location in the server as well as in the client since server is running: /path/ssh -l <CLIENT_LOGIN> client.zmanda.com $libexecdir/amandad to start the backup process.

While this is possible, it has two disadvantages:

1. You need to set up keys for both, ssh _and_ amanda.

2. You need to set up ssh keys either by storing the passphrase in cleartext or use ssh-agent. Using ssh-agent has security-flaws, too. In addition, with ssh-agent, you will need to type the passphrase at least once after every reboot. Not very suitable for a fully-automated backup-system, IMHO.

When you use a public key on the client to encrypt, you can lock away the private key in a secure place. Both, transport _and_ storage will be encrypted with such a setup.