SSH Notes

What Is SSH?

Collectively, SSH (Secure SHell) is a set of tools that allows a user on one computer access to a second computer. In includes several “shell” commands: ssh, scp, rsh, scp, and rsync are the ones I use on a daily basis.

These commands use a secured communication protocol that, at least in theory, keeps the communication secret. There’s no way for anyone to listen in or spoof the systems into allowing a third-party into the conversation.

Cryptographic Keys

When “keys” are added to the SSH mix, the second computer trusts the first computer’s authentication of the user who no longer has to type in a password to the second computer.

When I type in one of those commands, it initiates a connection to the server, supplies a user name, and through that user’s public and private keys, no password is required.

Important Terms

• Client - The computer where you or I sit. It (we) are the client.
• Server - The remote computer.
• Public Key - A cryptographic string, unique to the user, that must be on both computers.
• Private Key - A different cryptographic string, also unique to the user, that must be on the client computer, but no where else. (That is, you keep the private key secret!)
• Key Generation - This is the process of creating the public and private keys. NOTE: You or I will do this once on our computer, and as long as we don’t lose or distrust the generated keys, never again.
• Passphrase - An optional, password-like string to obscure your keys even more. You and I might do this if we fear someone might have access to our computer and steal our keys. (How paranoid are you? A lot: use the passphrase. Not much: skip it.)

Setting Up SSH with Keys

Because I do this rarely, I have usually forgotten the steps with I have to do it again.

That’s what these notes are for: Reminders of How To Do It.

Here’s the process.

One-Time Only

Overview

1. Generate your public and your private keys (see below) on your client (personal) computer.
2. Transfer only your public key to each server you intend to access. (Your private key is secret. Never give it to anyone or any other computer.)

1. Generating Keys

The two keys, public and private, must be created on your computer.

Note: Some server systems such as my web-hosting provider, for example, confusingly include this capability, and when I tell them I want to use SSH, they offer to generate my keys. But this offer of convenience generates more confusion than solution. Don’t do it. (Read on, please.)

ssh-keygen, executed on your client system, does the math, creates the two keys, and stores them in the right place. (If you wish, it will also encode them with a passphrase. More about that later.)

Note that most ssh-keygen implementations today will automatically default to using the RSA flavor of keys but there’s also a DSA flavor and some others. If it asks, choose RSA unless you have a compelling reason such as instructions from the boss to use a different flavor.

That’s step one, generating your public and private keys. ssh-keygen does the work (on your client [personal] computer.)

Next, you have to get your public key out to any server you want to use.

2. Transferring Your Public Key to a Server

Depending on the situation, this can be dirt-simple, or frustratingly complicated. You have to get your public key copied to the server, but it’s a chicken and the egg kind of problem.

You can use any of the following, depending on your circumstances. (Repeat it, once, for each server.)

1. The easiest is if you have SSH access to the server and can login using the old-school user name and password technique. If you can do that, ssh-copy-id username@server (on your client computer) will copy your public key to the server and store it in the right place. You’ll supply your username as part of the command, and it’ll ask you to type in your password. If it completes without error, you’re done; your public key has been copied to the server and stored.
2. Failing that, if you have ftp access to the server, then you would need a three-step solution: First, retrieve any existing .ssh/authorized_keys file from the server and save it on your client system, then use an editor to append your public key to it, and then third, upload that file back to the server storing it in your (remote) user’s .ssh/ directory.
3. Similarly, if you have some other direct access to the server system, you could edit the server’s .ssh/authorized_keys file and copy/paste your public key to it, perhaps from a USB memory stick or some other device.
4. Last ditch: If you don’t have any access to the server, you’ll need someone’s help. You’ll send them your public key (but never your private key), and they will add your public key to your account at the server in a .ssh/authorized_keys file that is unique to you.

Tip: If things get all mucked up, the server’s .ssh/authorized_keys file for that user should have only one line with your username and client computer association. If that association is in there multiple times, that’s wrong. The file will need to be hand-edited and the bad stuff removed.

About the Passphrase

Back when you generate your keys, you will be given the option of including a passphrase to help obscure your keys. While not required, it’s a good idea if your computer is accessible to others.

But on the other hand, you’ll have to type in the passphrase each time you initiate a connection, so it becomes as annoying as having to type your password each time. Developers often use the public and private keys extensions so they don’t have to type in passwords. Hence, they typically do not use the passphrase option.

You can toggle the passphrase off (or on) with the command ssh-keygen -p.

Reminders

If you are on a publicly-accessible computer such as at the public library, STOP. That’s a publicly-accessible client, and you never want your cryptographic keys, like the keys to your car, to be left out for anyone to borrow, steal, and wreck.

Second, if you are ever tempted to put your private key on another computer, STOP. Your private key is a secret. It belongs only on your (private) personal computer that no one else in the world can access.

Check the man-page for SSH. The designers have thought through most situations and the SSH capability has options for just about every scenario.

Recap

• You, the client, need both a public and a private key. ssh-keygen (on your personal computer) does the heavy lifting.
• You will then pass-out the public key to every Tom, Dick, and Harry (server system) you want to later use.
• But your private key is secret. It is for you and you alone. It needs to be on the client computer but no where else.
• The passphrase increases security but also means you’ll have to type something every time you initiate a connection. Most developers don’t use it.