How To:Set up transport encryption with SSH

This article is a part of the How Tos collection.

SSH provides transport encryption and authentication. To set up an SSH authentication session, Amanda will run the equivalent of:

/path/to/ssh -l <CLIENT_LOGIN> client.zmanda.com $libexecdir/amandad

to start the backup process.

To do so, you need to set up ssh keys either by storing the passphrase in cleartext, using ssh-agent, or using no passphrase at all. All of these options have security implications which should be carefully considered before adoption. This article describes setting up SSH keys with no passphrase. It should be fairly easy to adapt it to the other options.

When you use a public key on the client to do data encryption (see How To:Set up data encryption), you can lock away the private key in a secure place. Both, transport and storage will be encrypted with such a setup. See encryption for an overview of encryption options.

Setup

First, set up passwordless login between the amanda server and all clients. This requires two things: distributing SSH keys and setting up host keys. This page details the SSH configuration; the Amanda configuration is described authoritatively in amanda-auth(7).

SSH Keys

Create an ssh key for the Amanda server, and make sure you just hit enter when asked for a key passphrase. In this example, the key is put in the id_rsa_amdump file (Run this as the backup user - amandabackup or amanda):

 $ ssh-keygen -t rsa -C "SSH Key for Amanda Backups"
 Enter file in which to save the key (/home/amandabackup/.ssh/id_rsa)? /home/amandabackup/.ssh/id_rsa_amdump

Enable SSH authentication and set the ssh_keys option in all DLEs for that host by adding the following to the DLE itself or to the corresponding dumptype in amanda.conf:

 auth "ssh"
 ssh_keys "/home/amandabackup/.ssh/id_rsa_amdump"

Note that ssh_keys is the path to the private key you just created (without a .pub suffix). If the username to which Amanda should connect is different from the default, then you should also add

 client_username "otherusername"

If your server amandad path and client amandad path are different, you should also add

 amandad_path "/client/amandad/path"

Append the public key you created earlier (id_rsa_amdump.pub, not id_rsa_amdump) file to ~/.ssh/authorized_keys file on all Amanda clients.

For a marginal increase in security, prepend the authorized_keys line with the following:

 from="amanda_server.your.domain.com",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/absolute/path/to/amandad -auth=ssh amdump"

This will limit that key to connect only from Amanda server and only be able to execute amandad(8).

For client connections to the server, reverse the process -- put the public key (the same key or a new one -- your choice) on the clients, and the public key in the server's ~/.ssh/authorized_keys file. Prefix the authorized_keys line with:

from="amanda_client.your.domain.com",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/absolute/path/to/amandad -auth=ssh amindexd amidxtaped"

You can omit the from=.. option if you have too many clients to list, although this has obvious security implications.

Set ssh_keys and any other necessary options in /etc/amanda/amanda_client.conf:

 auth "ssh"
 ssh_keys "/root/.ssh/id_rsa_amrecover"
 client_username "amanda"
 amandad_path "/server/amandad/path"

Host Keys

Besides user keys, SSH uses host keys to uniquely identify each host, to prevent one host from impersonating another. One way to set up these host keys is to make a connection and tell SSH that you trust the identity:

$ ssh client1.zmanda.com
The authenticity of host 'client1.zmanda.com (192.168.10.1)' can't be established.
RSA key fingerprint is 26:4e:df:a2:be:c8:cb:20:1c:68:8b:cc:c0:3b:8e:9d.
Are you sure you want to continue connecting (yes/no)?yes

Since Amanda will not answer this question itself, you must manually make every connection (server to client and client to server) that you expect Amanda to make. This is a drag, but you only have to do it once.

You must ssh to exactly the domain name(s) in your disklist entries. To SSH, foo is not the same as foo.fully.qualified.domain.name.example.com.

The other option is to add

StrictHostKeyChecking no

to /etc/ssh/ssh_config. This may cause a failure on the first connection, but will automatically add the key to the database and work subsequently.

Non-Standard SSH Port

If SSH is running on a port other than 22, you can add the port in the dumptype

 client-port 2222

or edit the ~amanda/.ssh/config file to specify the appropriate port. For example:

 Host somehost.example.com
   Port 2222

inetd/xinetd

An inetd or xinetd entry is not needed for ssh auth.