SSH Keys

SSH requires authentication: proving who you are to the remote server that you are logging into (or copying to/from using SFTP).

Typically, we authenticate with passwords. But passwords are annoying for many reasons. To be good, they have to be long and (somewhat) complex (though see this wonderful XKCD cartoon about passwords which I have completely adopted).

In this course, we'll be working remotely, so we'll have to SSH and SCP to/from our local machine and the remote server (tempest) many times during an editing session, and consequently have to authenticate many times. Visual Studio Code will help with this, but it still requires multiple authentications.

Our goal with this reading is to understand how to streamline this process. We may never have to type our password again!

Concepts of Public Key Cryptography

The technique we will used is based on Public Key Cryptography. If you are curious, you should read more about it in that Wikipedia page. Here are the basic highlights:

  • cryptographic keys are generated in pairs
  • one is the public key, which is okay to share with others, and
  • the other is the private (or secret) key, which should never be shared with anyone.
  • each key can decrypt what the other has encrypted, and only that key can decrypt what the other has encrypted.

Public key cryptography can be used for either encryption or for authentication. We will use it for authentication. Later in the course, we may talk about how public key cryptography is used in encryption in the form of HTTPS (secure HTTP).

Authentication Using Public Keys

We're going to understand authentication using a little story about Alice and Bob in which Alice needs to authenticate herself (prove her identity) to Bob.

First, Alice generates an SSH key pair.

Suppose Bob and Alice meet and Alice proves her identity in some other fashion (maybe an ID card). She gives her public SSH key to Bob, who stores it safely.

Later, possibly over a network connection, Alice needs to prove her identity to Bob. She says "I'm Alice and I can prove it". Bob finds Alice's public key that he previously stored, generates a random number (called a nonce), and encrypts it with Alice's public key. He sends the encrypted random number to Alice and dares her to decrypt it and tell him what the number was.

Alice decrypts Bob's message using her private (secret) key, which is the only key capable of decrypting something encrypted with her public key. She tells Bob the random number.

Bob now knows that the person who claims to be Alice has Alice's private key, and therefore must really be Alice.

Public Key for SSH

The story of Alice and Bob is exactly how we will use public key to authenticate ourselves to the CS server. The CS server plays the role of Bob, and our laptop plays the role of Alice, who needs to prove her identity to Bob.

Here are the basic steps:

  1. We will generate a key pair on our laptop using the command ssh-keygen That puts a pair of files in our ~/.ssh/ directory, namely id_rsa and id_rsa.pub
  2. We will copy the the id_rsa.pub file to the server (tempest) using ssh-copy-id: ssh-copy-id user@host. We will have to use our server password to authenticate ourselves this time.

The second step saves the public key in the ~/.ssh/authorized_keys file on the CS server.

Note that the commands are done on your laptop, not on the CS server.

Steps on a Mac

In the last section, I accompanied the commands with explanatory text, but sometimes that makes it harder to see what you have to do and what the computer's response will look like. Below is a transcript of my doing these commands on my personal (Mac) laptop using the terminal application. See ssh if you've forgotten about the terminal.

I have highlighted in bold four commands. The first two (ssh-keygen and ssh-copy-id) I described in the last section. (I also highlighted in bold where I entered my password.) The third command is suggested by ssh-copy-id to test for success, and using it shows that we no longer have to give our username/password to login to cs.wellesley.edu. (Notice the changed prompt, indicating where we are.) The fourth command logs out of the server, returning us to our laptop.

ScottAndersonMBP:~ scott$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/scott/.ssh/id_rsa): 
Created directory '/Users/scott/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /Users/scott/.ssh/id_rsa.
Your public key has been saved in /Users/scott/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:f6f+4PgJqef8fDAfBk4Dwn7dIMKAVl6S0gpoA4UFcok scott@ScottAndersonMBP
The key's randomart image is:
+---[RSA 2048]----+
|=B+. ++=.        |
|E+o +.oo= o .    |
|. .o o.. o + o   |
|    .   . . = .  |
|        S. o o   |
|         . .+ o  |
|          + o=.. |
|         o.* =o  |
|        .o++Oo.  |
+----[SHA256]-----+
ScottAndersonMBP:~ scott$ ssh-copy-id anderson@cs.wellesley.edu
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/scott/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
anderson@cs.wellesley.edu's password: .........

Number of key(s) added:        1

Now try logging into the machine, with:   "ssh 'anderson@cs.wellesley.edu'"
and check to make sure that only the key(s) you wanted were added.

ScottAndersonMBP:~ scott$ ssh anderson@cs.wellesley.edu
Last login: Wed Aug 19 10:27:24 2020 from pool-108-20-176-82.bstnma.fios.verizon.net
This is the new virtual server running CentOS 7
[anderson@tempest ~]$ logout
Connection to cs.wellesley.edu closed.
ScottAndersonMBP:~ scott$

Steps on Windows

On the Wellesley lab image, we can use the OpenSSH implementation in Windows PowerShell. See Windows 10 ssh-copy-id Hopefully something like that will work on your personal laptop.

Go Ahead

I encourage you to do this on your own time. Contact me if you have any trouble.

Limitations/Warnings

Protect your private key. Anyone with your private key can log into your account on the server.

Anyone with access to the account that stores your private key will be able to log into the server. Don't allow that to happen!

Presumably, you already protect your personal laptop, so this is just reinforcing your current practice.