SSH keys are a convenience for interating with our Dept Linux servers and a necessity for the Dept Gitlab and other network services.

1 ssh Isn’t Just for Terminal Sessions

You should already be familiar with ssh even if you are used to invoking it through PuTTY.

We’re going to start by working with ssh from a command line. You will be working with

• a client machine, at which you can issue ssh commands. This could be one of the CS Dept Linux servers, or from a terminal session on your own PC if it runs Linux, OS/X, or CygWin.

• a server machine, which will be one of the CS Dept Linux servers.

  If you choose to use sirius.cs.odu.edu for your client machine, then use atria.cs.odu.edu for your server, or vice versa. I will assume in the rest of this document that you are using atria as your server.

Let’s start with just the basics of using ssh from the command line.

1. Try opening a remote session on your server machine by issuing the following command on your client machine:

   ssh -l yourCSLoginName atria.cs.odu.edu

   • You can omit the “-l yourCSLoginName” if your current terminal session is under a user name identical to your CS Dept login name. You can also combine it with the machine name, separated by an “@”:

     ssh yourCSLoginName@atria.cs.odu.edu

   This opens up a familiar text-mode command session on the remote machine. Issue a few commands to verify that everything is familiar, and then log out of the remote machine.

2. Now give the same command, but append a command string to the end:

   ssh -l yourCSLoginName atria.cs.odu.edu ls -l

ssh is useful for issuing all sorts of commands to a remote machine. The “default” is to issue the command to open a login shell, but you can issue any command you want.

ssh has other tricks to offer as well.

• ssh servers also, by default, provide file copying services via scp and sftp..

• The ssh protocol can act as a “tunnel” for other common network protocols (e.g., email). This includes protocols that normally are limited to local network connections or that, for other reasons, have trouble getting through firewalls and routers. For example, all of the techniques covered in CS252 for connecting via X Windows have actually relied upon an ssh tunnel to carry the X or NX protocol messages between the two machines.

2 Replacing Passwords with ssh Keys

ssh keys provide a way of identifying yourself that is generally more secure than simple passwords. Based on one-way cryptography, an ssh key has two parts: a public key and a private key. You can distribute the public key to a variety of server systems that you like to log in to. You keep the private key on client machines that you log in from. Often these client machines are ones you have a certain amount of physical control over — a home computer or a laptop that you own. That physical security is coupled with a lengthy passphrase needed to activate the private key. Once activated, the private key can be kept active through a work session, allowing you to repeatedly log in to clients that have your public key.

2.1 Generate a Key Pair

The ssh-keygen program is most commonly used to generate public/private key pairs. Most Linux systems will have this already installed. On a Windows CygWin system, you can get it as part of the openssh package. [^ssh-keygen-sources]

[^ssh-keygen-sources]: Another possibility is Pageant, part of the PuTTY ssh suite for Windows. Also, you can generate keys from within Eclipse (Window $\Rightarrow$ Preferences $\Rightarrow$ General $\Rightarrow$ Network Connections $\Rightarrow$ SSH2 $\Rightarrow$ Key Management, but the key length is limited to 1024 bits, which is considered a bit low these days.

1. To generate a key pair, give the commands (on your client machine):

   mkdir ~/.ssh   # if you don't already have this directory
   chmod 700 ~/.ssh
   ssh-keygen -b 2048 -t rsa
   

   You can change the name of the generated files if you like. (I keep different key pairs for different client machines and name them accordingly, e.g., “officePC”, “homePC”, etc.). Do keep it in your ~/.ssh directory, however.

   You will be prompted for a passphrase. This is used to protect your private key in case someone gains access to the machine/account where you have it stored. Do choose one. Even though the command prompt says it’s optional, you don’t want to have an unprotected private key around. Most people use much longer passphrases than a typical password, but generally place less emphasis on odd character substitutions that make the phrase harder to type.

2. Now look in your ~/.ssh directory. You should see your new keys. One file has the extension “.pub”. that’s the public part of the key.

2.2 Try It Out

1. Let’s establish this key as one that you can use to log in to your CS Linux account.

   To use an ssh key pair to log into your account on a server, you have to “authorize” that pair. On Linux servers, you do this by adding the public key to ~/.ssh/authorized_keys. authorized_keys is simply a text file that contains a list of public keys.

   There’s two ways to do this.

   • The quick way, if your client machine has the ssh-copy-id command, is to do

     ssh-copy-id -i yourPrivateKeyFilename  yourCSLogin@atria.cs.odu.edu
     

   • Alternatively, upload the public part of the key to your CS account on your chosen server machine. On that machine, create a “~/.ssh” directory if you don’t have one:

     mkdir ~/.ssh   # if you don't already have this directory
     chmod 700 ~/.ssh
     

     Then add the new key to your authorized key list:

     cd ~/.ssh
     touch authorized_keys
     cp -a authorized_keys authorized_keys.bak
     cat yourPublicKeyFilename >> authorized_keys
     

   • As yet another alternative, log in to the server, open ~/.ssh/authorized_keys in an editor and add the public key to the end. (This is also how you can clean up this file later if you want to remove a key, either because the key doesn’t work properly or to clean up after this assignment is done and graded.)

2. Now, back on your client machine, try connecting to the server:

   ssh -i yourPrivateKeyFilename -A yourCSLogin@atria.cs.odu.edu
   

   You should be prompted for the passphrase for your new key.

If you run into problems with this step or with the ones that follow, check your permissions very carefully. You should have the equivalent of:

chmod 711 ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

2.2.1 ssh Agents

Wait, did we just make your life harder?

Now, you may wonder what good that was. Every time you try to log in to a CS Linux machine, you will be prompted for that passphrase, which is probably much longer than your old password.

But usually, we don’t activate the private key for a one-shot login. Instead, we run a key agent on our client machine. We tell it to activate our private key (giving it the passphrase to prove that we are its owner). It then watches for subsequent ssh connection attempts and offers up the activated private key.

1. On your client machine:

   eval `ssh-agent`
   ssh-add ~/.ssh/yourPrivateKeyFilename
   

   Take note that the ssh-agent command is inside backticks, not apostrophes.

2. Then try giving the following commands from your client

   ssh yourCSLogin@atria.cs.odu.edu date
   ssh yourCSLogin@atria.cs.odu.edu pwd
   ssh yourCSLogin@atria.cs.odu.edu ls
   ssh -A yourCSLogin@atria.cs.odu.edu
   

   All of these should work with your being prompted at most once for your passphrase. The last one leaves you logged in to atria. From that session on atria, try logging in to sirius:

   ssh sirius.cs.odu.edu
   

   Again, you should find that you are able to do this without being prompted for your password or passphrase. The -A option in the earlier ssh command caused your agent’s credentials to be forwarded into your session on atria.

If you like this, you should look into the package keychain, which is a way to set up agents and activate your keys upon logging in to your client. If you don’t care for it, restore your authorized_keys file in your CS account to its previous state (the .bak file). But keep those keys. We’ll use them later.