SSH Configuration Activity

Overview

SSH, or Secure Shell is a ubiquitous method of remote access to servers. SSH provides that tough balance between state-of-the-art encryption and secure remote access. SSH also provides a myriad of configurations. In today's activity, we'll learn how to properly set up SSH key pairs and other customizations.

Today we will work with the two main implementations of SSH: PuTTY and OpenSSH. PuTTY is the Windows implementation, and OpenSSH is the Unix-like implementation (i.e. Linux and OpenBSD).

For this activity, we will be using SSH in two ways:

• From Windows to Linux using PuTTY in Windows and OpenSSH on nitron.se.rit.edu
• From Linux to OpenBSD using OpenSSH on nitron.se.rit.edu and OpenSSH on control.se.rit.edu

This activity will require you to do some research through documentation. While Googling is permitted, be forewarned that the Internet has a lot of misinformation about properly setting up these systems. I suggest consulting man pages first.

Activity

This activity is intended to be done individually, or in pairs.

1. First, let's set up a public and private key to remote from Windows to Linux. PuTTY and OpenSSH are compatible, but the differ slightly in their algorithms.
2. Open up PuttyGen. If you need to download it, download the executable here.
3. Generate a new key for this activity. Give it a passphrase (password) of your choosing. For the comment field, put your username and "-ssh-activity" (e.g. bob1234-ssh-activity).
4. Save the public and private key somewhere on your local Windows machine. You always want to keep that private key a secret, and that public key can be posted anywhere. Name both with the "-ssh-activity" suffix. By convention, PuTTY public keys have no file extension, and private keys have a ".ppk" extension. (Those conventions are different for OpenSSH.)
5. At this point, you have some unique keys. But nitron has no idea that it should trust your keys as being from you. So we need to tell nitron that your public key is actually yours. Open up PuTTY and sign into your SE account. Keep the PuTTYGen program open.
6. If you do not already have a directory called ".ssh" in your home directory, create it: mkdir ~/.ssh
7. Open up (or create) the file ~/.ssh/authorized_keys in your favorite text editor (vim, nano, etc.).
8. Paste your OpenSSH key from the PuttyGen window (note: this is NOT your PuTTY public key, it's the OpenSSH version of your public key that PuTTYGen provides). Shift+Insert is handy way to paste text into vim via PuTTY.
9. Save the file and close your PuTTY console.
10. Now let's authenticate using pageant. Run pageant, and add your PuTTY key. You will need to fill the passphrase you set before.
11. Open up PuTTY and sign into nitron.se.rit.edu. Once you enter your username, you should not need to enter a password. The very first lines of your console should be:

    Using username "[your username]".
Authenticating with public key "[your username]-ssh-activity" from agent

    If this second line is not there, your setup is not correct. You should not be asked for your password in PuTTY (only your passphrase for adding your key to pagent in the previous step).
12. Restricted Command Exercise. Now that we have authenticated properly using pageant, let's further secure this authorized key. Change authorized_keys such that the user authenticating using this key is only allowed to run the sqlite client on a database called "mydb.sqlite" in their home directory.
13. OpenSSH exercise. Sign into control.se.rit.edu from nitron.se.rit.edu using ssh-agent. Research how to do this. You may generate new keys for this. You should be able to SSH into control.se.rit.edu without typing in a password.
14. Attempt to break Restricted Command. Using the setup from the previous two exercises, attempt to SSH into a server and execute a command using this syntax (changing bob1234 to your username)
    $ ssh bob1234@control.se.rit.edu /bin/bash
    sqlite should still be executed and the /bin/bash command should be ignored.
15. Discussion Questions with the class. Come up with answers to these questions, and we will discuss them in class:
    • If using SSH key pairs and authenticating agents means I have to enter in my password less often, why are SSH key pairs more secure?
    • What might be a vulnerability of the sqlite command restriction exercise? Specifically, is there anything in the sqlite client that might be a security risk?
    • Some SSH clients allow you to create a public/private pair without a passphrase. What are the specific risks of this?
16. Important! Remove this activity key from your authorized_keys if you don't plan on using it in the future.

Submission & Grading

This activity is worth 10 points, and your grade is based on in-class participation. Nothing is due beyond class today, as long as you are participating and are reasonably close to completion. There is no GoogleDoc or any other artifact to grade, but you will need to know this material for the exam (as with all activities).