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_ecdsa and id_ecdsa.pub¹
2. We will copy the the id_ecdsa.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.

Visualization¶

In the following figure, we are pretending that Wendy Wellesley has set up SSH keys to the CS server.

• on Wendy's Mac laptop, the account name is wendy so the home directory is /Users/wendy
• on the CS server, the account name is ww123, so the home directory is /students/ww123
• there is a .ssh directory in both home directories. We don't have to create those; they will either exist or be created automatically.

• Step 1 (ssh-keygen) creates the key pair on our laptop.
• Step 2 (ssh-copy-id) appends the id_ecdsa.pub file to the authorized_keys file on the remote machine.

Warning¶

The most common error is to do these commands on the remote machine.

Don't do that. Do the commands on your laptop, with just one exception.

Please check your prompt before doing a command, so that you are sure you are doing the command on the correct machine.

I suggest not using VSCode, because VSCode makes it too easy and tempting to start a remote terminal.

Instead, I suggest starting a local terminal (PowerShell on Windows).

Steps on a Mac¶

In the earlier 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.

One other bit of reassurance: when you type your password, nothing will be printed, not even a dot. That's normal; don't let it bother you.

ScottAndersonMBP:~ scott$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/Users/scott/.ssh/id_ecdsa): 
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_ecdsa.
Your public key has been saved in /Users/scott/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:f6f+4PgJqef8fDAfBk4Dwn7dIMKAVl6S0gpoA4UFcok scott@ScottAndersonMBP
The key's randomart image is:
+---[ECDSA 256]---+
|=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_ecdsa.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¶

If you have a Windows machine, don't despair. SSH works on Windows. (Though you may have to install it. See SSH Windows 11)

However, Windows lacks the useful ssh-copy-id command, so we'll have to do the following steps. Note that the ww123@cs below is a placeholder; you'll replace it with your username.

Also, don't forget the colon at the end of the second argument to the scp command; that indicates that the file is on another host, but in the home directory of your account on that host.

1. ssh-keygen -t ecdsa (same as on a Mac)
2. Copy id_ecdsa.pub to remote machine:
   1. copy the file to the server (remember the colon): scp .ssh/id_ecdsa.pub ww123@cs:
   2. login to the server: ssh ww123@cs
   3. append the file: cat id_ecdsa.pub >> .ssh/authorized_keys
   4. delete the pub file: rm id_ecdsa.pub
   5. logout from the server: logout

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.