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.
- 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.
- 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.)
- 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.
- Upload your silly message both encrypted and unencrypted to the
remote computer.
- 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.
- 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.
- 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.
- 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.)
- 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!