Automate Backups on Linux

By Martyn Honeyford
2005-04-20

Secure Remote Access Using Public/Private Keys

In the context of digital security, a key is a piece of data which is used to encrypt or decrypt other pieces of data. The public and private key scheme is interesting because data encrypted with a public key can only be decrypted with the associated private key. You may freely distribute a public key so that others can encrypt the messages they send you. One of the reasons that public/private key schemes have revolutionized digital security is because the sender and receiver don't have to share a common password. Among other things, public/private key cryptography has made e-commerce and other secure transactions possible. In this article, we'll create and use public and private keys to create a highly secure distributed backup solution.

Each machine involved in the backup process must be running the OpenSSH secure shell service (sshd) with port 22 accessible through any intermediate firewall. If you access remote servers, then there is a good chance you're already using secure shell.

Our goal will be to provide machines with secure access without requiring the need to manually provide passwords. Some people think that the easiest way to do this is to set up password-less access: do not do this. It is not secure. Instead, the approach we'll use in this article will take perhaps an hour of your time, set up a system which gives all the convenience of "passphraseless" accounts -- but is recognized as being highly secure.

Let's begin by ensuring that OpenSSH is installed and proceed to check its version number. At the time this article was written, the latest OpenSSH release was version 3.8, released on February 24, 2004. You should consider using a recent and stable release, and at the very least use a release which is newer than version 2.x. Visit the OpenSSH Security page for details regarding older version-specific vulnerabilities (see the link in Resources later in this article). At this point in time, OpenSSH is quite stable and has proven to be immune to many of the vulnerabilities which have been reported for other SSH tools.

At a shell prompt, type ssh with the capital V option to check the version number:

$ ssh -V
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f

If ssh returns a version number greater than 2.x, the machine is in relatively good shape. However, it is recommended that you use the latest stable releases of all software, and this is especially important for security-related software.

Our first step is to log in to the offsite storage server machine using the account, which will have the privilege of being able to access servers 1 and 2 (see Figure 1).

$ ssh accountname@somedomain.com

Once logged on to the offsite storage machine, use the ssh-keygen program to create a public/private key pair using the -t dsa option. The -t option is required, and is used to specify the type of encryption key we're interested in generating. We'll use the Digital Signature Algorithm (DSA), which will enable us to use the newer SSH2 protocol. See the ssh-keygen man page for more details.

During the execution of ssh-keygen, you'll be prompted for the location where the ssh keys will be stored before you're asked for a passphrase. Simply press enter when asked where to save the key and the ssh-keygen program will create a hidden directory called .ssh (if one doesn't already exist) along with two files, a public and private key file.

An interesting feature of ssh-keygen is that it will allow you to simply press enter when prompted for a passphrase. If you don't supply a passphrase, then ssh-keygen will generate keys which are not encrypted! As you can imagine, this isn't a good idea. When asked for a passphrase, make sure to enter a reasonably long string message which contains alphanumeric characters rather than a simple password string.

Listing 3. Always choose a good passphrase

[offsite]:$ ssh-keygen -t dsa

  Generating public/private dsa key pair.

  Enter file in which to save the key (/home/accountname/.ssh/id_dsa):

  Enter passphrase (empty for no passphrase): (enter passphrase)

  Enter same passphrase again: (enter passphrase)

  Your identification has been saved in /home/accountname/.ssh/id_dsa.

  Your public key has been saved in /home/accountname/.ssh/id_dsa.pub.

  The key fingerprint is:

  7e:5e:b2:f2:d4:54:58:6a:fa:6b:52:9c:da:a8:53:1b accountname@offsite

Because the .ssh directory which ssh-keygen creates is a hidden "dot" directory, pass the -a option to the ls command to view the newly created directory:

[offsite]$ ls -a
. .. .bash_logout .bash_profile .bashrc .emacs .gtkrc .ssh

Enter the hidden .ssh directory and list the contents:

[offsite]$ cd .ssh
[offsite]$ ls -lrt
id_dsa id_dsa.pub

We now have a private key (id_dsa) and a public key (id_dsa.pub) in the hidden .ssh directory. You can examine the contents of each key file using a text editor such as vi or emacs, or simply by using the less or cat commands. You'll notice that the contents consist of alphanumeric characters encoded in base64.

Next, we need to copy and install the public key on servers 1 and 2. Do not use ftp. Rather, use the secure copy program to transmit the public keys onto each of the remote machines:

Listing 4. Installing the public keys on the remote servers

[offsite]$ scp .ssh/id_dsa.pub accountname@server1.com:offsite.pub

   accountname@server1.com's password: (enter password, not new

   passphrase!)

   id_dsa.pub 100% |*****************************| 614 00:00



   [offsite]$ scp .ssh/id_dsa.pub accountname@server2.com:offsite.pub

   accountname@server2.com's password: (enter password, not new

   passphrase!)

   id_dsa.pub 100% |*****************************| 614 00:00

After we install the new public keys, we'll be able to sign on to each machine using the passphrase we specified when creating the private and public keys. For now, log in to each machine and append the contents of the offsite.pub file to a file called authorized_keys, which is stored in each remote machine's .ssh directory. We can use a text editor or simply use the cat command to append the offsite.pub file's contents onto the authorized_keys file:

Listing 5. Add offsite.pub to your list of authorized keys

[offsite]$ ssh accountname@server1.com

accountname@server1.com's password: (enter password, not new

passphrase!)

[server1]$ cat offsite.pub >> ./ssh/authorized_keys

The next step involves employing a bit of extra security. First, we change the access rights for the .ssh directory so that only the owner has read, write, and execute privileges. Next, we'll make sure that the authorized_keys file can only be accessed by the owner. And finally, we'll remove the previously uploaded offsite.pub key file, since it's no longer required. It's important to ensure that access permissions are properly set because the OpenSSH server may refuse to use keys which have non-secure access rights.

Listing 6. Changing permissions with chmod

[server1]$ chmod 700 .ssh

[server1]$ chmod 600 ./ssh/authorized_keys

[server1]$ rm offsite.pub

[server1]$ exit

After completing the same process on server2, we are ready to return to the offsite storage machine to test the new passphrase type access. >From the offsite server you could type the following:

[offsite]$ ssh -v accountname@server1.com

Use the -v, or verbose flag option, to display debugging information while verifying that your account is now able to access the remote server using the new passphrase rather than the original password. The debug output displays important information which you might not otherwise see, in addition to offering a high level view of how the authentication process works. You won't need to specify the -v flag on subsequent connections; but it is quite useful to do so while testing a connection.

Tutorial Pages:
» No Excuses: do-it-Yourself, Secure, Distributed Network Backups Made Easy
» Simple Backups
» Advanced Backups
» Secure Remote Access Using Public/Private Keys
» Automating Machine Access Using SSH-Agent
» Simplifying Key Access Using Keychain
» Scripting a Backup Process
» Scheduling
» Verifying Your Backups
» Additional Security Precautions
» Conclusion
» Resources

First published by IBM DeveloperWorks

Related Tutorials:
» How to Install PHP 5 on Linux
» How to Install Apache 2 on Linux
» How to Install MySQL 5.0 on Linux
» SMB Caching
» Mound --Bind
» Tar Wild Card Interpretation