BackupPC FAQ: SSH Setup


Why do I need SSH?

SSH is a secure way to run tar or rsync on a backup client to extract the data. SSH provides strong authentication and encryption of the network data.

Note that if you run rsyncd (rsync daemon), ssh is not used. In this case, rsyncd provides its own authentication, but there is no encryption of network data. If you want encryption of network data you can use ssh to create a tunnel, or use a program like stunnel. If someone submits instructions I will include them.

Back to Top


How do I setup OpenSSH?

Depending upon your OpenSSH installation, many of these steps can be replaced by running the scripts ssh-user-config and ssh-host-config included with OpenSSH. You still need to manually exchange the public keys.

Key generation

As root on the client machine, use ssh-keygen to generate a public/private key pair:

    ssh-keygen -t rsa

This will save the public key in ~/.ssh/id_rsa.pub and the private key in ~/.ssh/id_rsa, if you don't specify another location. As a password, you would type nothing (just enter) if you wish BackupPC to start automatically; alternatively, you could set a password on the private key as stored in the file system, and use an agent as described below to store the private key without password only in memory.

BackupPC setup

Repeat the above steps for the BackupPC user (__BACKUPPCUSER__) on the server. Make a copy of the public key to make it recognizable, eg:

    ssh-keygen -t rsa
    cp ~/.ssh/id_rsa.pub ~/.ssh/BackupPC_id_rsa.pub

See the ssh and sshd manual pages for extra configuration information.

Key exchange

To allow BackupPC to ssh to the client as root, you need to place BackupPC's public key into root's authorized list on the client. Append BackupPC's public key (BackupPC_id_rsa.pub) to root's ~/.ssh/authorized_keys2 file on the client:

    touch ~/.ssh/authorized_keys2
    cat BackupPC_id_rsa.pub >> ~/.ssh/authorized_keys2

You should edit ~/.ssh/authorized_keys2 and add further specifiers, eg: from, to limit which hosts can login using this key. For example, if your BackupPC host is called backuppc.my.com, there should be one line in ~/.ssh/authorized_keys2 that looks like:

    from="backuppc.my.com" ssh-rsa [base64 key, eg: ABwBCEAIIALyoqa8....]

Also, you need to place the client's public key into backuppc's ~/.ssh/known_hosts file, otherwise you will get a

    Host key verification failed.

error, and backuppc will not be able to log into the client. To place the client key into the ~/.ssh/known_hosts file, you need to do this (make sure ~/.ssh/client_id_rsa.pub is the client's public key, which needs to be copied from the client):

    touch ~/.ssh/known_hosts
    cat ~/.ssh/client_id_rsa.pub >> ~/.ssh/known_hosts

Repeat this step for every client.

Fix permissions

You will probably need to make sure that all the files in ~/.ssh have no group or other read/write permission:

    chmod -R go-rwx ~/.ssh

You should do the same thing for the BackupPC user on the server.

Testing

As the BackupPC user on the server, verify that this command:

    ssh -l root clientHostName whoami

prints

    root

You might be prompted the first time to accept the client's host key and you might be prompted for root's password on the client. Make sure that this command runs cleanly with no prompts after the first time. You might need to check /etc/hosts.equiv on the client. Look at the man pages for more information. The -v option to ssh is a good way to get detailed information about what fails.

Back to Top


How do I setup SSH2?

Key generation

As root on the client machine, use ssh-keygen2 to generate a public/private key pair:

    ssh-keygen2 -t rsa

or, because this command is sometimes renamed to ssh-keygen:

    ssh-keygen -t rsa

This will save the public key in ~/.ssh2/id_rsa_1024_a.pub and the private key in ~/.ssh2/id_rsa_1024_a. As a password, you would type nothing (just enter) if you wish BackupPC to start automatically; alternatively, you could set a password on the private key as stored in the file system, and use an agent as described below to store the private key without password only in memory.

Identification

Create the identification file ~/.ssh2/identification:

    echo "IdKey id_rsa_1024_a" > ~/.ssh2/identification
BackupPC setup

Repeat the above steps for the BackupPC user (__BACKUPPCUSER__) on the server. Rename the key files to recognizable names, eg:

    ssh-keygen2 -t rsa
    mv ~/.ssh2/id_rsa_1024_a.pub ~/.ssh2/BackupPC_id_rsa_1024_a.pub
    mv ~/.ssh2/id_rsa_1024_a     ~/.ssh2/BackupPC_id_rsa_1024_a
    echo "IdKey BackupPC_id_rsa_1024_a" > ~/.ssh2/identification

Based on your ssh2 configuration, you might also need to turn off StrictHostKeyChecking and PasswordAuthentication:

    touch ~/.ssh2/ssh2_config
    echo "StrictHostKeyChecking ask" >> ~/.ssh2/ssh2_config
    echo "PasswordAuthentication no" >> ~/.ssh2/ssh2_config
Key exchange

To allow BackupPC to ssh to the client as root, you need to place BackupPC's public key into root's authorized list on the client. Copy BackupPC's public key (BackupPC_id_rsa_1024_a.pub) to the ~/.ssh2 directory on the client. Add the following line to the ~/.ssh2/authorization file on the client (as root):

    touch ~/.ssh2/authorization
    echo "Key BackupPC_id_rsa_1024_a.pub" >> ~/.ssh2/authorization
Fix permissions

You will probably need to make sure that all the files in ~/.ssh2 have no group or other read/write permission:

    chmod -R go-rwx ~/.ssh2

You should do the same thing for the BackupPC user on the server.

Testing

As the BackupPC user on the server, verify that this command:

    ssh2 -l root clientHostName whoami

prints

    root

You might be prompted the first time to accept the client's host key and you might be prompted for root's password on the client. Make sure that this command runs cleanly with no prompts after the first time. You might need to check /etc/hosts.equiv on the client. Look at the man pages for more information. The -v option to ssh2 is a good way to get detailed information about what fails.

Back to Top


How do I setup SSH version 1?

The concept is identical and the steps are similar, but the specific commands and file names are slightly different.

First, run ssh-keygen on the client (as root) and server (as the BackupPC user) and simply hit enter when prompted for the pass-phrase:

    ssh-keygen

This will save the public key in ~/.ssh/identity.pub and the private key in ~/.ssh/identity.

Next, append BackupPC's ~/.ssh/identity.pub (from the server) to root's ~/.ssh/authorized_keys file on the client. It's a single long line that you can cut-and-paste with an editor (make sure it remains a single line).

Next, force protocol version 1 by adding:

    Protocol 1

to BackupPC's ~/.ssh/config on the server.

Next, run chmod -R go-rwx ~/.ssh on the server and chmod -R go-rwx ~/.ssh on the client.

Finally, test using:

    ssh -l root clientHostName whoami

Back to Top


What are the security implications when using SSH?

Using ssh is quite secure, but the security is only as good as the protection of ssh's private keys. If an attacker can devise a way to run a shell as the BackupPC user then they will have access to BackupPC's private ssh keys. They can then, in turn, ssh to any client machine as root (or whichever user you have configured BackupPC to use). This represents a serious compromise of your entire network.

So in vulnerable networks, think carefully about how to protect the machine running BackupPC and how to prevent attackers from gaining shell access (as the BackupPC user) to the machine.

Back to Top


How can an agent improve security?

An agent is a background program that stores your private keys in memory, without password protection on them. If your memory is well-protected and swapping is not going to give problems, then your agent is a safe place to store the private keys. The long-term storage of the private keys can be in a password-protected file in the file system.

When you create your keys with ssh-keygen or ssh-keygen2 you are prompted for a password. If you would type nothing, the file system version of the keys is not protected with a password, which makes their security quite fragile. An agent is a better idea.

To start the agent in the background, run the following command once:

    eval `ssh-agent`

or, on commercial SSH systems:

    eval `ssh-agent2`

The agent will determine what shell you are using and will send properly formatted statements to eval, which sets a few environment variables that SSH will recognise as hooks to the agent.

The next step is uploading your keys to the agent. During this process you will be prompted for the password so that the agent can store the decrypted passwords. You can upload keys simply by doing:

    ssh-add

or, on commercial SSH systems:

    ssh-add2

The installation of the public key at the client machines remains the same, since this key is never protected with a password -- it is public. If you now try to connect from the server to a client you will not be asked for a password, since the agent is used to bypass that.

At this point, you can start BackupPC -d. BackupPC's children inherit the environment variables, which in turn are passed onto ssh, can then contact ssh-agent to get the private keys. This allows BackupPC to run ssh without unprotected private keys being available on the file system.

It is possible to forward an agent over an SSH connection, so you can even decide to take the private key store out of the BackupPC server, at the cost of having to log in there from a trusted (desktop) machine.

Finally, there are options to store the private key in a specialised token, such as a smart card or a cryptographic USB device. This can be done, for example, with the experimental -I option to OpenSSH (see http://www.openbsd.org/cgi-bin/man.cgi) or with a replacement of the agent (see http://openfortress.nl/product/shaman) -- the former would only work on the machine and thus keep the credentials for accessing the smart card on the BackupPC server, while the latter can be forwarded from a trusted machine like any other agent.

However, even the use of ssh-agent doesn't provide complete protection. If an attacker can run a shell as the BackupPC user, they can access the agent to get the keys. However, using ssh-agent does provide an extra layer of protection since no unprotected private keys are stored anywhere on the file system.

[This section was contributed by Rick van Rein.]

Back to Top


How can client access as root be avoided?

Rather than ssh as root, you can create a low-privileged backuppc user on the client, and use sudo on the client to run the backup command (eg: tar or rsync) as root.

Josh Marshall reports he uses ssh with a non-root user (e.g. backuppc) and use sudo as part of the rsync command on the remote end.

Configure sudo using visudo on the client like this:

    backuppc  ALL=NOPASSWD: /usr/bin/rsync

This means that the only command that backuppc can run is rsync. Then set the RsyncClientCmd to be something like:

    $Conf{RsyncClientCmd} = '$sshPath -l backup $host nice -n 19 sudo $rsyncPath $argList+';

In this case Josh nices the backup so that it doesn't give such a performance hit on the client. The same setup works for tar.

Note that an attacker who can become the backuppc user on the server can then ssh to the client and use sudo to run /bin/tar as root. Importantly, this means they can write files anywhere on the file system by doing tar -x or using rsync to copy files. This is sufficient to allow an attacker to become root on the client machine.

This is better than the default setup above, since getting the ssh key on the server immediately allows an attacker to ssh to the client as root.

If you want to be more cautious, you could create a short shell script (eg: rsyncSend) that includes the --sender argument argument from $Conf{RsyncClientCmd}, eg:

    #!/bin/sh -f
    exec /usr/bin/rsync --server --sender $*

Make sure this script and all parent directories have no write permission. Then change the $rsyncPath in $Conf{RsyncClientCmd} to rsyncSend:

    $Conf{RsyncClientCmd} = '$sshPath -l backup $host nice -n 19 sudo /path/to/rsyncSend $argList+';

and finally use visudo to change the allowed command to /path/to/rsyncSend.

A similar setup for tar would ensure that an attacker can only run tar -c (create), and not be able to write files on the client. Create a short script, eg, tarCreate:

    #!/bin/sh -f
    exec /bin/tar -c $*

Make sure this script and all parent directories have no write permission. Then remove the -c from $Conf{TarClientCmd} and change the tar path:

    $Conf{TarClientCmd} = '/usr/bin/sudo /path/to/tarCreate -v -f - -C $shareName+ --totals';

Finally, run visudo to change the allowed command to /path/to/tarCreate.

Martin Hansen notes that a simpler alternative to using a script is to enforce the arguments directly with sudo, eg:

    backuppc  ALL=NOPASSWD: /usr/bin/rsync --server --sender *

This causes sudo to only accept the /usr/bin/rsync command with those arguments, the * at the end tells sudo to accept more arguments after --sender.

In the cases above, a compromise of the backuppc user on the server still allows the attacker to ssh to the client and run tar -c or rsync --sender via sudo. But this only allows them read access to files on the client, which they already have access to simply by inspecting the BackupPC backup data directories on the server.

Back to Top


SourceForge Logo
This page last modified 2006-12-11 09:53
© Copyright 2001-2005 Craig Barratt. BackupPC is hosted by SourceForge and distributed under a GPL license.