CS 251: Generating ssh keys

Overview

Later in the term, we're going to be using git, which is a version control system for managing files. We'll talk about the details of that much later, but Mike Tie (our department system administrator) and his students need to get started now on setting up the server for it so that it will be working when we're ready to use it.

All of you will need to be able to authenticate yourselves to the department git server. The most common form of authentication is the use of a password. Most of the time that you log into a computer, you authenticate yourself (i.e., you "prove" you are who you say you are) by entering in a password that presumably only you know.

An alternative form of authentication, which is used by our git server, uses RSA encryption techniques with a private and public key pair. If you haven't come across these ideas before, here's the concept. Bear in mind that all of these details are handled by software automatically, so you do hardly any of this yourself.

  1. Use RSA encryption software to generate a pair of files. The first file is called a "private key," and contains a random-seeming sequence of bits that you keep hidden and don't show anyone. Ever. This file, by default, is called id_rsa. The second file is called a "public key," and you can share it with the world. It looks like another random-seeming sequence of bits, and is by default typically called id_rsa.pub. Specifically, share the public key with a remote server or computer you wish to log into.
  2. When you go to log into the remote computer and are asked to authenticate yourself, your software first generates a random silly message like "Hi my amazing friends, hope you are tangy". (Ok, it's actually not pretty text like this, but it's actually a random sequence of bits. I'm going to use the message to keep the idea simple.) A different message is generated every time you try to log on.)
  3. Using your private key, the software encrypts that message. The only way to decrypt that message, as it turns out, is to use the public key.
  4. Upload your silly message both encrypted and unencrypted to the remote computer.
  5. The remote computer uses your public key to try decrypt your message, and checks if it matches the unencrypted version of the message you sent. If it decrypts the message and sees gobbledy-gook, it blocks you out. No login for you! You must not have had the right private key because your message encrypted wrong. On the other hand, if the decrypted message matches your unencrypted message, i.e. the message decrypts to "Hi my amazing friends, hope you are tangy", then you must have had the private key. If someone had used a different key, that person wouldn't have known how to produce the correct encrypted message that matched with the public key. Voila! The remote computer lets you log in.

In practice, this means that you need to generate a private key and a public key for yourself, share your public key with the remote computer (once), and place your private key in the right location on your computer (once). After that, you can authenticate automatically as much as you like.

Specifics

You need to generate a private and public key pair so you can authenticate against the department git server. If you've already done this for some other purpose, you may want to jump to the appendix at the bottom of this assignment. You can safely ignore that if you've never done this before.

  1. Go into one of our department labs, and log onto one of our lab computers. Open up a terminal window. Alternatively, if you have ssh, PuTTY, or some other ssh-like program installed on your home computer, use it to log into skittles.mathcs.carleton.edu.
  2. In the terminal window, type in:

    ssh-keygen -b 4096 -t rsa

    This runs the program ssh-keygen, which generates a pair of private and public keys in the directory .ssh, each of which are 4096 bits long. That's long enough to satisfy even Mike Tie that security is good enough. "rsa" indicates a specific style of RSA encryption. There are other varieties. Mike likes this one.
  3. You will be prompted to enter a passphrase to attach to your private key. This has nothing to do with your typical Carleton password -- you can pick a different one here if you choose. This protects you against theft of your private key file. If someone somehow manages to steal your private key file, they still can't read it or use it without the passphrase. (Technically, what actually happens is that your private key file is encrypted, and the passphrase is necessary for decrypting it.)
  4. That's it. If you're curious, go look in your .ssh directory, and you should find files id_rsa and id_rsa.pub. What usually happens in practice is that you need to submit your id_rsa.pub file to the remote computer in some way. In this case, since Mike Tie has access to everyone's accounts, he will (without poking around) simply copy that file out of your .ssh directory into the appropriate location.

Appendix

If you already have created private/public keys, you may already have the files that Mike needs without needing to do the steps above.

If you're a pro at doing this and maintain multiple private/public key pairs for use with different remote computers, you'll need to create a pair with different filenames for this purpose (as opposed to your other pairs). I'll assume that if you're at this stage, you can figure out how to do this, but I can happily answer questions. If you want Mike to take a public key with a different filename than id_rsa.pub, place a mtie.txt file in your .ssh directory with explanations for Mike as to how he should handle.

Acknowledgments

Much of the work on setting up the git server, and much of the work on configuring your accounts, has been/will be done by Andy Freeland. Thanks, Andy!