dixie state college logo
dixie cit it cs vt degrees courses faculty facilities jobs submit login
dixie > cit > cs > cs2810 >



Computer and Information Technology

  Degrees
  Courses
  Faculty
  Facilities
  Contact
  Jobs
  Scholarships
  ACM Club
CS 1010 1400 1410 2420 2450 2810 3400 3410 3500 3510 3520 3530 3600 4300 4550 4600 3310
Home Syllabus Schedule Log Grading

CS 2810 Computer Organization and Architecture

Configuring ssh to access lab machines

It is often convenient or even necessary to connect to CIT machines from your laptop or some other machine outside the campus firewall. This can be a nuisance, because the firewall prevents you from connecting directly. ssh has options to make this simpler.

Public key authentication

The first step is to set up public-key authentication so you do not need to type your password when connecting. On the “source” machine (your home machine, laptop, etc.), check if you have a public key:

cat ~/.ssh/id_rsa.pub

If the file is not found, generate a public key:

ssh-keygen

The default options are usually sufficient (I usually leave the passphrase blank as well). With older versions of ssh-keygen, you may be required to specify that you want to use RSA:

ssh-keygen -t rsa

Note that if you run ssh-keygen again, it will clobber your old key, so you will have to set up remote machines to accept your new key.

Next, connect to the “target” machine (the one you want to be able to access), and instruct it to use your public key for authentication. Do this by adding it to your authorized_keys file, or creating it if it does not exist. It is located in the ~/.ssh directory as well. If you have to create the .ssh directory, restrict access to it:

mkdir ~/.ssh
chmod 700 ~/.ssh

Copy the id_rsa.pub file from your source machine to the authorized_keys file on your target machine. If authorized_keys already exists, you can add the new key to the file. You can add as many keys as you want, but be careful. If you lose the private key associated with it (or your laptop is stolen, etc.) you should delete the corresponding private key from your authorized_keys file.

Now you should be able to ssh from the source machine to the target without using a password.

Configuring ssh

ssh lets you configure the details of connecting to remote machines to save typing. For example, my username on my desktop machine is russross, but my username on the lab machines is russ. To connect to a machine like oxygen, I normally have to type:

ssh russ@oxygen.cs.dixie.edu

If I want X11 forwarding (where I launch a GUI application on oxygen, but the window pops up on my desktop machine), I need to use:

ssh -X russ@oxygen.cs.dixie.edu

To simplify things, I create a file called config in my .ssh directory with an entry for each machine I contact. For example:

Host oxygen
    User russ
    ForwardX11 yes
    HostName oxygen.cs.dixie.edu

With that in place, I can just type:

ssh oxygen

and all of the options are taken from the config file. The name I need to type (oxygen) is arbitrary and can be any nickname; ssh looks at the HostName entry to decide where to actually connect.

Connecting through the firewall

To connect to oxygen from home, I first have to connect to a machine like ssh.cs.dixie.edu that sits outside the firewall. Then I can connect from there to oxygen in a two-step process:

ssh ssh.cs.dixie.edu
ssh oxygen

This has a couple of disadvantages:

  1. It’s two steps and I’m lazy
  2. It doesn’t work with scp, git, rsync, and other tools that use ssh as a secure transport
  3. X11 forwarding does not work across this link
  4. To avoid typing a password, I have to configure oxygen to trust ssh.cs.dixie.edu using a public key. I would rather avoid that because ssh.cs.dixie.edu sits outside the firewall and is more likely to be compromised than a machine inside the firewall.

I am happy to have ssh.cs.dixie.edu trust my source machine (someone breaking into ssh.cs.dixie.edu would not be able to do anything with my public key, except let me connect to their machines without a password). I am also happy to have oxygen trust my home machine. I would like to use ssh.cs.dixie.edu to create a secure tunnel that forwards my ssh session directly from my home machine to oxygen.

Here’s how to do it:

  1. Set up ssh.cs.dixie.edu to trust my home machine by installing my home machine’s public key in the authorized_keys file on ssh.cs.dixie.edu
  2. Same thing for oxygen–its authorized_keys file should include my home machine’s public key
  3. In the config file on my home machine, add an entry for oxygen like this:

    Host oxygen User russ ForwardX11 yes HostName oxygen.cs.dixie.edu ProxyCommand ssh -l russ ssh.cs.dixie.edu exec nc %h %p

The information in the ProxyCommand line is for connecting to ssh.cs.dixie.edu, and the information in the rest of the entry is for connecting to oxygen.

Now from my home machine I can type:

ssh oxygen

and the following things happen automatically:

  1. ssh connects to ssh.cs.dixie.edu using my public key.
  2. It runs nc oxygen.cs.dixie.edu 22 on ssh.cs.dixie.edu, which uses a utility called netcat to connect to the ssh server on oxygen. The connection originates from ssh.cs.dixie.edu, so the firewall is not a problem.
  3. ssh uses the tunnel from my home machine through ssh.cs.dixie.edu to oxygen to set up a new ssh session that communicates directly with oxygen.
  4. The private key on my home machine is used to authenticate me on oxygen directly.

As a user, it appears that I am connecting directly; the firewall is invisible. X11 forwarding works as well.

Tools that use ssh

Other tools use ssh to establish secure connections. These include rsync, scp, and git among others. Any settings you establish in your config file apply to these tools as well, so I can synchronize files from my home machine to oxygen using something like:

rsync -av evilassignment oxygen:

and it uses my config file settings and public key settings to establish the connection without requiring a password or other inconvenient steps.

Student Projects   
CIT.DIXIE.EDU