Getting More Out of SSH

by Apratt

Everyone who sends private data over computer networks should learn how to take full advantage of SSH.

SSH is not just a Telnet replacement, and you may be surprised just who is reading everything you type.

Five years ago in college, I was quite surprised to learn that an acquaintance on the third floor of my dorm was able to read AIM messages from me to someone off campus.  I lived in the basement and he was separated from me by a few hundred feet of Ethernet cable as well as a few Cisco 1900 switches.  I didn't even think this guy was a computer enthusiast, but I suppose an Ethernet sniffing program can make an enthusiast out of anybody.  Luckily, we were on good terms and he showed me what he was doing.  You can bet that most people who use Ethernet sniffers don't let their victims know about it.

In this article, I will assume OpenSSH is the SSH package you use, but the information should apply to other SSH packages as well.

Most people just use SSH as an "encrypted Telnet."  Even if this is the only way you want to use it, you should at least know about SSH's features that make it more convenient than Telnet.

You can execute commands on the remote computer without even really logging in.  When using SSH from your command line, simply add the command you wish to remotely execute to the end of your SSH command.

For example, where you would normally type:

$ ssh apratt@college.edu

Type this instead:

$ ssh apratt@college.edu "ls public_html/*.jpg"

Hit Enter, give SSH your password when prompted, and the task is done.

If you use a private key file instead of a password (see below), there's even less you have to do.

Passwords used to be annoying to remember and type all the time, but not so with SSH.  You can have SSH make you a private key file which acts as your password.  If used properly, a private key file is more secure than a regular password due to its increased size and complexity.

You may think that each character in your password equates to eight-bits of a passkey.  However, consider this: your password probably doesn't contain "high" ASCII characters (often represented by hearts, rectangles, foreign characters, etc.) or control characters (stuff like Escape, Tab, and Enter).  This means that instead of each password byte containing 1 of 256 possible characters, it probably only contains 1 of 96 or so.  Each character of a good password is really only worth about 6.5 bits.  The default length of a private key file is 1024-bits.  Plus, using a computer-generated private key file prevents your users from selecting a password like "sex", "password", or their phone number.

You can even encrypt your private key file with a passphrase for even more security.  The Bad Guys would then need to possess both your private key file and the passphrase to decrypt it.  Personally, I think that's overkill and just have a passphrase-less private key file and a normal password to use when I can't use that.  To have SSH make you a private and public keypair for use with the SSH2 protocol, use this command:

$ ssh-keygen -t dsa

If you prefer the RSA algorithm, just replace the dsa option with rsa.

If you want keys for use with SSH1, replace dsa with rsa1.

SSH1 and RSA each have some associated security problems and no real advantages over DSA, so you may as well stick with DSA-type keys and SSH2.

ssh-keygen will ask you where you want your keys stored (the default is probably fine) and what passphrase to encrypt your new private key with.

Abstaining from encrypting your private key with a passphrase will result in greater convenience, but you must make darn sure that only you can access that key.  An unencrypted keyfile is just like a text file containing your password.

It can be stolen by an Ethernet sniffer if it is sent over a network by FTP, NFS, email, etc.  (SSH doesn't actually send your key file during login, so that won't get it stolen.)  Also be certain that its file permissions are configured to prohibit others from reading it.  Anybody who 0wns, confiscates, or steals your computer will be able to access every account that relies upon your key!

The good news is that you can store your private key on something you can take with you, such as a mini-CD-RW, SanDisk, JumpDrive, MP3 player, USB wristwatch, whatever.

Note that if SSH thinks your private key has the wrong file permissions, it will refuse to use it, and applying file permissions is tricky on many of those media.

The server(s) you plan on connecting to with your new private key will need a copy of your new public key.  Your public key file contains a really long line of nonsensical text and, as the name implies, you don't need to keep that text secret.

If your destination server will only have one public key of yours, use FTP or whatever you prefer to copy your public key (id_dsa.pub by default) to .ssh/authorized_keys in your remote home folder on the destination server.

If .ssh/authorized_keys already exists there, just add your new line of text onto the end of the preexisting file on the next line.

SSH should automatically look for your private keyfile (.ssh/id_dsa in your local home folder by default) and use that instead of bothering you for a password from now on.  I you store your private key somewhere else, such as on a mini-CD-RW use the -i option like so:

$ ssh -i /dev/cdrom/id_dsa apratt@college.edu

Making an appropriate symlink from your mini-CD-RW-based private key to .ssh/id_dsa will keep you from having to use the -i option needlessly.

One more thing about the mini-CD-RW with your private key on it: don't label it "MY SECRET KEY."  Write "Camping Photos" on it or something boring like that.  There's no need to attract unwanted attention from The Bad Guys.

scp is the SSH-ified version of cp (UNIX's file copying command).  To download a file, the command is:

$ scp college.edu:spring_break.mpg .

This example assumes the file you want is in your remote home folder.  The lonely period at the end is just UNIX's way of saying "Put the file in the folder I'm currently in."

To upload a file, simply reverse the arguments (no lonely period needed this time):

$ scp spring break.mpg college.edu:

You can even use a different username, specify a certain location, and rename the uploaded file at the same time:

$ scp spring_break.mpg jsmith@college.edu:/home/apratt/public_html/homework.mpg

Now that SSH doesn't ask you for a password, you can even make a script or cron-job to execute remote commands while you sleep.  I like to schedule scp downloads and uploads for 3 am when bandwidth is plentiful.

Using sftp is like using other command-line FTP programs.  get, put, chmod, the main stuff's all in there.  The main difference is that all communication is handled by a single SSH connection, as opposed to the unencrypted multi-connection silliness that is standard FTP.

It should be noted that everyone should protect their private key files with a passphrase to prevent them from being stolen.

However, if you're not afraid of people stealing your persistent website login cookies or saved email password (both of which are usually sent unencrypted over the LAN/Internet), then leaving your SSH private key file "unpassphrased" isn't that big a deal.

Depending on your paranoia level and SSH usage pattern, ssh-agent (included with OpenSSH) or Pageant (part of the PuTTY suite) may be a good compromise of convenience and security.  These programs let you have encrypted keys, but cache your passphrase until you quit them.

Some Free SSH Clients

OpenSSH: www.openssh.org

MacSSH: www.macssh.com

PuTTY: www.chiark.greenend.org.uk/~sgtatham/putty

Return to $2600 Index