eRacks Systems Tech Blog
Open Source Experts Since 1999
Putting SSH Keys to Work
There may be situations where you’d like to login to a remote machine via SSH and not have to enter a password to do it. Perhaps you have some sort of automated file transfer that makes use of SCP. Or, perhaps you frequently login to the same machine and get tired of having to enter a password each time. Whatever the reason may be, an attractive alternative to using passwords involves making use of cryptographic keys.
To give you a general idea of what’s involved, you’ll first generate a public/private key pair. Your public key is what you would copy to every machine you want to be able to log into. You can think of the public key as the lock on a door to a house. The reason why we call this a public key is that it’s safe to share it with the public, just as the lock on your door is safe to display from the outside. By contrast, your private key can be thought of as the key that fits into the lock. Unlike your public key, you should never copy it to machines that are either untrusted or to machines that you yourself don’t administer — this would be a bit like placing the key to your front door outside your house for strangers to use! Anybody who possesses your private key can access every machine to which you’ve made your public key accessible, so exercise extreme caution and guard your private key with your life.
SSH makes generating your keys very simple. From the command line, you’ll simply enter the following command:
$ssh-keygen
You’ll then be asked a series of questions. Accept all the defaults. If you don’t desire to password protect your key pair (which would require you to enter a password when you use it), hit enter when asked for the password, without typing anything in. At the end of the process, you should discover two new files in ~/.ssh, id_rsa and id_rsa.pub, where ~ stands for your home directory. From here, you’ll copy your public key (id_rsa.pub) to every machine you wish to log into and append its contents to a file called ~/.ssh/authorized_keys, where ~ stands for the home directory of the account you wish to log into.
To test your newly generated key pair, try to connect to one or more of the remote machines you copied your public key to. You’ll find that you’re sent straight to a command prompt, without the need for a password.
Now, there are situations where using keys without passwords can potentially be hazardous, so some significant thought should be given to the circumstances in which your key pair will be used. For example, I will never copy my laptop’s public key to my personal server at home, because if my laptop is ever stolen, the thief (if he knew how to use *NIX) would not only have access to all my local data, but would also have complete SSH access to my network at home, since he would have my laptop’s private key. Thus, I choose to sacrifice convenience for security in that particular situation. As with all things in life, the amount of relative security versus convenience is a trade off, so make sure you choose wisely.
Enjoy!
james November 21st, 2008
Posted In: authentication, security, ssh, unix
Tags: authentication, key, linux, private, public, ssh, ssh-keygen, unix
Useful commands for backing up filesystems
Have you ever needed to backup the contents of one or more filesystems to another machine, yet you only had a single hard drive in the machine being backed up and found that you lacked the temporary disk space necessary to create your backup before shuttling it across the network to its final destination?
As an example, when I backup my laptop, I have too many gigabytes of data to realistically store my data on DVD-R’s, and my only option is to create a tarball of the root filesystem and store it on another machine on my network. The problem is that if I try to create a backup of my laptop’s contents, I find that the resulting tarball backup is too large to fit on the hard drive along with all the data.
One solution that I’ve found to this problem is to avoid storing the backup on the source machine altogether. Through stdin and stdout, along with the magic of *NIX pipes, we can stream the data in realtime over to its destination, and only then write it to disk.
Before we begin, it is very important to note that in most situations, you’ll have to boot into another environment and manually mount your partition before proceeding, particularly when dealing with an operating system’s root filesystem. Otherwise, not only will tar choke on certain directories like /proc and /dev, the contents of the disk will also continue to change as the backup is being made, leading to inconsistencies between the data on your filesystem and the data in the backup.
With that in mind, assuming that you have ssh installed and configured correctly on both the source and destination computers, you can create a backup with the following commands (as root):
#cd /path/to/your/mounted/filesystem
#tar -jcvp | ssh username@destination “cat > /path/to/backup.tar.bz2”
If you prefer to use gzip as opposed to bzip2, replace the above tar command with the following:
#tar -zcvp | ssh username@destination “cat > /path/to/backup.tar.gz”
Now, let’s say that you’ve created a new partition and want to restore a previous backup. Again, assuming that ssh is configured properly on the source and the destination machines, and assuming that you’ve mounted your partition, you would recover your backup with the following commands (again, as root):
#cd /path/to/your/mounted/filesystem
#ssh username@destination “cat /path/to/backup.tar.bz2” | tar -jvxp
If the backup is a gzipped archive, then replace the above tar command with the following:
#ssh username@destination “cat /path/to/backup.tar.gz” | tar -zvxp
Note that the user specified by ‘username’ above should have read/write permissions on the directory where the backup is to be stored for this procedure to work.
The astute reader will probably notice the missing -f option, which one usually passes to tar. The reason for this is that it tells tar to write its data to, or read its data from, a file. However, by ommitting it, we tell tar to send its output to stdout, or to receive its data from stdin when reading from an archive, which allows us to make use of pipes. It’s situations like these where the power of *NIX really shines!
james May 28th, 2008
Posted In: Backups
Tags: backup, bzip, bzip2, filesystem, gzip, partition, ssh, zip