LBackup is designed to pull data from the client(s) to the server via the network.

• Quick overview of network backups : LBackup screencasts page.
• Different network backup strategies : Push and Pull Network Backup Strategies page.
• Why LBackup uses openSSH for network backups : Why SSH?
  • SSH agent information for unattended network backups.
    • What is an SSH agent?
    • SSH agent usage.

LBackup relies upon hard links to reduce disk usage.

Mac OS X dose not support the creation of hard links on network mounted volumes. Therefore, the destination of a backup should not be a volume mounted via the network. However, a push of data over the network is possible if the destination volume is a mounted disk image. This is because the creation of hard links are supported on mounted disk images under Mac OS X, regardless of whether the image file resides locally or on a remote host.

Utilizing a network for backup purposes offers a variety of advantages. In particular, network(s) offer a convenient way to quickly move data to various physical locations.

SSH offers various layers of integrity and security. As such in many network backup configurations SSH is an appropriate tool to use for data transport.

Below there links to various tutorials to assist with your understanding of the setup of SSH connections. In addition, further down on the page there is additional information regarding the configuration of LBackup to perform a network backup via SSH.

Finally, if you are visually inclined then you may wish to view the online screen cast of configuring LBackup for a network backup.

• Visit the screencasts page to visually learn how to install and configure LBackup

Below the basic SSH Backup steps are outlined.

1. Setup the SSH backup
2. Generate keys pairs
3. Configure the access on the server using the public key
   1. Generate the SSH directory and authorized_keys2 / authorized_keys files as required
   2. Test access to the server from the client
   3. Configure the backup user on the server so that the correct key is used for the host
4. Enable the SSH wrapper scripts for additional security.
5. Test the backup is working and that any important files are protected

The plan is to bundle a script to assist with the setup of many of the steps listed above. If you are interested in helping with this aspect of LBackup then the developer automated SSH setup page may be worth a visit.

If you are planning to implement a network backup, using SSH as the data transport mechanism, then an invaluable web based resource is Mike Bombich's “remote backup of Mac OS X using RSync page. In addition Michael Solberg's article ”RSync Backups on OS X“ also contains useful tips regarding the setup of SSH Keys. Also the ”Backup with rsync and SSH“ tutorial by Sydney Weidman may be helpful. If you are interested in an SSH key specific information then look at Dave Aaldering's tutorial or this great tutorial. Finally, the primary source of authoritative information regarding SSH is official SSH web site.

• SSH server configuration is beyond the scope of this documentation.
• Configuring LBackup for Network Backup

Below are the various options which are required within an LBackup configuration file, in order to perform a network backup via SSH.

1. Ensure that the option 'useSSH' is set to 'YES'.
2. Ensure that the option 'sshRemoteUser' is set appropriately. The example below sets this to 'root'.
3. Ensure that the option 'sshRemoteServer' is set appropriately. The example sets this to an IP address of '192.168.1.100'.

Below is an example snippet from the 'example_backup.conf' LBackup configuration file. These are the default settings for this file.

 sshRemoteUser="root"
 sshRemoteServer="192.168.1.100"
 useSSH="YES"

Unless absolutely necessary, do not allow your backup as root. If root login is a requirement for a backup then you may wish to ensure that password login for root is disabled. In addition, limit root logins to a specific host may only take place from your backup server. One possible approach is to configuring pam.d to only allow root login from a specific host. Although configuring your SSH server is beyond the scope of this documentation there are some introductory notes available on the SSH server configuration page.

If you are using SSH keys to authenticate your SSH sessions, then there are some RSA/DSA tutorials (part 1, part 2, part 3) kindly hosted by IBM.

An example of how you could create an SSH Keypair in a testing directory is outlined below. The steps listed are only an example.

(It is reccomeded that you read the tutorials listed above gain a firm understand what is happening, beyond the inline comments).

 # Step (1) : change directory (home directory)
 cd                    

 # Step (2) : create a directory (testingdirectory)      
 mkdir testingdirectory

 # Step (3) : change permissions (newly created directory)
 chmod 700 testingdirectory  

 # Step (4) : change directory (testingdirectory)
 cd testingdirectory   
 
 # Step (5) : generate a dsa ssh key piar 
 ssh-keygen -t dsa -f ./backupclient_backup_dsa -C "Used to backup the backupclient" 

 # Step (6) : print the current directory listing (showing the newly created ssh key pair)
 ls -l

You have just created two key files in the 'testingdirectory' which is located in your home directory. One will be called 'backupclient_backup_dsa' and the other will be called 'backupclient_backup_dsa.pub'. These are the private and public keys respectively.

For production purposes you may require different options when creating the SSH keys.

If the public key ./backupclient_backup_dsa.pub created in the previous section is concatenated onto the end of a file called '~/.ssh/authorized_keys2' / '~/.ssh/authorized_keys' (Mac OS X 10.8 and later), which is located on a remote machine which has SSH access enabled, then you will be able to login this server from any system with ssh and the private key ./backupclient_backup_dsa.

The command 'scp' will allow you to copy the public key to a remote server which to which you have access. Then you can add the public key line to the end of your '~/.ssh/authorized_keys2' / '~/.ssh/authorized_keys' on this server. Finally, if this was all successful you will now be able to login to this server using the ./backupclient_backup_dsa . On many systems there is a '-i' flag for ssh which will allow you to specify the private key you would like to use when logging into a system.

Provided you created the public keys in the previous section and are still in this terminal and have the same working directory then the following commands should add this key to the '~/.ssh/authorized_keys2' / '~/.ssh/authorized_keys' file for testing purposes. The first command checks if there is an .ssh directory on your ssh server. If there is not an ssh directory it will create this directory. If you are sure there is an .ssh directory on the remote server then you can safely skip the first step.

 
 # Step (1) : ensure the remote .ssh directory exists.
 ssh username@servername "if ! [ -d ~/.ssh ] ; then mkdir .ssh ; chmod 700 .ssh ; fi" 

 # Step (2) : copy the local public key to the remote systems .ssh directory.
 scp ./backupclient_backup_dsa.pub username@sshservername:~/.ssh/

 # Step (3) : login to remote system
 ssh username@sshservername

 # Step (4) : change directory to the remote systems .ssh directory
 cd .ssh

 # Step (5) : append the freshly copied public key to the authorized keys file on the remote system.
 #            note : on Mac OS X 10.8 and later the file should be authorized_keys rather than authorized_keys2
 cat ./backupclient_backup_dsa.pub >> authorized_keys2

(Please note that these steps are intended for testing purposes only).

If the commands above were run successful (either manually or as an interactive script) then you should now be able to login to the server using the private key.

  ssh -i ./backupclient_backup_dsa username@servername

However, please keep in mind that there are many configuration options for ssh both on the client and the server. If you are experiencing problems there are many potential reasons. For instance your servers administrator may have disabled key pair authentication.

Note (1) : You may find the utility 'ssh-copy-id' to be helpful when setting up access with key-pairs. 'ssh-copy-id' will be particularly useful should you be configuring access to a number of backup clients.

Note (2) : This page is not going to go into details about securing your SSH server. However, one thing which you may want to do is disable root logins or at least disable root login via password authentication. Below are a couple of approaches to editing the sshd_config file to disable root login via passwords, while still allowing password authentication via SSH to this host. The second approach which uses the Match directive will allow you to match users other than root. If root is not going to require access then it would be advisable to disable root login on your host.

# Allow password authentication but disable password authentication for root (one possible approach)
PasswordAuthentication yes
PermitRootLogin without-password

# Allow password authentication but disable password authentication for root (another possible approach)
PasswordAuthentication yes
PermitRootLogin yes
Match User root
PasswordAuthentication no

Additional information regarding keeping password authentication enabled but disabling root authentication is available from various sources. Below are just a couple of helpful links relating to such information and discussions :

• Stack Excharge : Permit root to login via SSH only with key based authentication (website)
• SSH, The Secure Shell: The Definitive Guide (book)

If you are using SSH keys to for authentication to clients, then you can assign a key per host name or IP address. There are a variety of places to set these options. In the example below we will illustrate how to configure the backup users setting file '~/.ssh/config' to set the specific SSH key based on the hostname.

# SSH Configuration File 

    host hostname1
            IdentityFile    ~/.ssh/sshkey1

    host hostname2
            IdentityFile    ~/.ssh/sshkey2

Because this configuration file is located within the backup users home directory, it will only effect the backup users SSH sessions.

There is an example LBackup SSH wrapper script installed within the LBackup example setup directory. There are also other resources available for restricting what is allowed with an SSH wrapper. Below are just a few examples :

• Restrict rsync to a subdirectory wrapper

You may find that by combining one or more of these approaches / examples will result in an solution ideal solution to meet your requirements.

SSH wrapper scripts allows the system administrator to limit the available commands when using a specified SSH key as the authentication for a session. This is accomplished by running the wrapper script after successful authentication. This wrapper script now in control of the SSH session can dictate what will happen in the session and which commands will and will not be allowed.

Included within the LBackup download you will find a modified version of Mike Bombich's great SSH RSync wrapper script. The wrapper currently included in with LBackup is an older version of this wrapper. This older version has been tested with LBackup. If you are willing to try the latest version, then it is recommended that you visit ”remote backup of Mac OS X using RSync“ to download and test the latest version of this SSH RSync wrapper script.

Included in the LBackup example configuration folder is an LBackup SSH wrapper script. The modified example wrapper script limits the available shell commands to a set of LBackup related commands.

Follow the steps below to install the wrapper script. In this example we will install the wrapper into '/etc/ssh_wrappers/lbackup-wrapper.sh'. However, please consider the security implications of installing this wrapper script.

  # Step (1) : create the /etc/ssh_wrappers directory. on some systems,
  #            you may want to put this within the /etc/ssh directory
  sudo mkdir /etc/ssh_wrappers

  # Step (2) : change directory into the newly created directory
  cd /etc/ssh_wrappers

  # Step (3) : ensure that root is the owner of this new directory
  sudo chown root:0 /etc/ssh_wrappers

  # Step (4) : set permissions on the directory
  sudo chmod 711 /etc/ssh_wrappers

  # Step (5) : copy the example file into the recently created /etc/ssh_wrappers directory
  sudo cp /etc/lbackup/example_backup_config/resources/ssh-wrappers/lbackup-wrapper.sh ./

  # Step (6) : ensure that root is the owner of this file
  sudo chown root:0 /etc/ssh_wrappers/lbackup-wrapper.sh

  # Step (7) : restrict permissions on the installed wrapper script (note : this may be too restrictive)
  sudo chmod 500 /etc/ssh_wrappers/lbackup-wrapper.sh

Note : If you receive the following error message you will need to install the tcsh shell. On Debian or debin directives the command sudo apt-get install tcsh should be that is requried. Error Message : /etc/ssh_wrappers/lbackup-wrapper.sh: /bin/tcsh: bad interpreter: No such file or directory

Also please keep in mind that the instructions above a very generic installation. As mentioned above, you may want to create a separate backup user rather than using the super user for running these backups. If you would like other users on the system have the ability to use this the lbackup-wrapper script then issue the following command :

• 'sudo chmod 755 /etc/ssh_wrappers/lbackup-wrapper.sh'

The command above will allow everyone on the system to read and execute lbackup-wrapper.sh. It is of course possible to use various permission models to restrict access to this the lbackup-wrapper.sh. Keep in mind that this script is an example script and will probably require tweaks in order to meet your requirements.

To activate the wrapper add the following information to the start of the appropriate entry in '~/.ssh/authorized_keys2', '~/.ssh/authorized_keys' or which ever file(s) on your system is used for public key authorization.

 # BSD Based Systems (Including Mac OS X)
 command="/private/etc/ssh_wrappers/lbackup-wrapper.sh" 

# LINUX based systems
 command="/etc/ssh_wrappers/lbackup-wrapper.sh" 

Then test that you have successfully restricted access to only the commands you require for the backup.

A big thank you to Mike Bombich for developing this great web resource and for allowing the inclusion of the wrapper scripts within the LBackup distribution.

Under no circumstances should you assume a machine is safe, just because you have installed a wrapper-script. If you are at all unsure of how this wrapper affects the security of your system, do not use it.

Installation of the wrapper will only affect SSH sessions which are passed to the wrapper. This means that to practically secure systems effectively using this example wrapper script, you may need to implement additional security measures such as hardening the SSH server, creating a wrapper for the backup command allowing it be run as a non-privileged user, running a general security audit on the system, as well as ensuring physical access restrictions to the system are in place.

If you are setting up a network backup from a LINUX machine to a Machine running Mac OS X, and you are happy to use the standard version of rsync which ships with Mach OS X, then you may want to consider enabling the options listed below :

# Override local system checks
 check_local_system="NO" # (Bypasses the local system checks) 

# Allow the use of the standard version of rsync when performing the backup (YES/NO)
 ssh_permit_standard_rsync_version="YES"

Once you have generated your SSH keys, you may be interested in securing the SSH key with a pass-phrase. However, this makes an unattended backup slightly more complex. In order for an automated SSH connection to be established using a password protected SSH key, the pass-phrase will somehow need to entered automatically. Luckily, this problem has already been solved by a handy tool called an SSH-agent.

Mac OS 10.5 and later have an SSH-agent installed by default.

If you are planning on using an SSH Agent, you may want to consider learning more about how it works. A few links for getting started with SSH Agent are listed below :

• SSH Agent
• Wikipedia
• Berkley
• Security Focus
• keychain

Finally, Mac OS X has a great GUI ssh-agent called SSH KeyChain.

If you decide to use Cron to schedule your backups and you would like to use an SSH Agent to manage the pass-phrases for your key paris, then it is possible to instruct cron to connect to the ssh-agent via the ssh-agent socket.

export SSH_AUTH_SOCK=/path/to/your/ssh-agent.socket ; /usr/local/sbin/lbackup /path/to/your/lbackup/backup.conf

You will need to modify this to be a valid socket and a valid LBackup configuration file.

Once this command is scheduled with Cron, authentication assistance from you ssh-agent should work via this socket. However, this is certainly not the only way of connecting to an ssh-agent from Cron.

For instance you may prefer to load a pre-hook script which exports various environment variables for connecting to your server. In fact it is even possible to start the ssh-agent before the backup and then stop the ssh-agent when the backups have completed successfully.

If you are running 10.5 and would like to use the built in ssh-agent the please refer to the LBackup ssh-agent developer instructions.

Alternatively, you may want to experiment with simply add the SSH_AUTH_SOCK settings as a command directly into the crontab.