3.3 SSH+sudo

This approach is, in a way, superior to a networked file system method. One reason is that it works over the Internet. NFS and SMB by themselves are not very secure protocols. On a trusted LAN, they may be reasonably secure. However, over the Internet, neither can be trusted. Kerberos can be used to secure NFS and SMB. On the other hand, NFS and SMB are not very efficient, either. Running a networked file system over the Internet can be very slow.

SSH is a protocol designed to work over an untrusted network. Username, password and data are all encrypted. Furthermore, connection authentication can be key-pair based, which also helps to improve security.

To automate SSH, it is critical to use authorized keys. This part is covered in another module that discusses the use of SSH itself. See module 0125 for more details. As always, make sure the private key is well protected! Check the owerships and permissions of the key files and the .ssh folder.

If root log in is permitted, then it is quite easy to back up a remote machine using the following command, run from tarpool:

However, for security reasons, most hosts do not allow root log in. This means that we need another account for log in purposes. Let’s say we create the account backup on jd just for back up purposes. You should set up backup as a regular user account.

Do not add backup to the root group if you value the security of your data! This is not going to help our task, anyway.

Instead, we rely on a program called sudo. This command allows a regular user to have additional privileges for certain commands. Use visudo to add an entry on jd as follows:

This entry specifies that the account backup may execute the command /bin/tar as root. The NOPASSWD option means that when the user backup wants to raise its privilege to root (for the tar command), no password will be asked. This still requires the authentication as backup. As a result, the account backup should have a strong password to thwart users on jd from gaining unauthorized access.

Next, we can run the following command on tarpool to create a backup file:

Of course, you can customize this command to make it more fancy. Nonetheless, this command executes the sudo tar command remotely on jd, and captures the output to the local file backup.tgz on tarpool.

To make this scheme even more secure, you should read the manual page of sshd and customize authorized_key of backup at jd. For example, the use of from can help restrict connections to tarpool. This means that even if someone gets a hold of the private key file, tarpool refuses to connect unless the SSH connection is initiated from tarpool. If this feature is combined with disabling password login, then all SSH connections to jd should be quite secure.

Note that this method creates a complete backup of jd on tarpool. If bandwidth is limited, or there is too much data to backup, then other methods can be used. For example, rdiff-backup can be used for remote incremental backups. See http://arctic.org/ dean/rdiff-backup/unattended.html for more details about how to set it up. The tutorial assumes root log in is permitted via SSH. If that is not permitted, you can use sudo to permit a non-root user raise to root privilege (but only for a restricted list of commands, such as rdiff-backup).

Whether you use tar or rdiff-backup, both are essential clients of ssh. This means from a security stand point, they are equivalent.