Skip to Content

Secure Shell (SSH)

The department only allows Secure Shell (SSH) connections to our systems for interactive sessions. telnet, the old standard, sends plain-text passwords and session information across the network. Those passwords can easily be intercepted and used to gain access to accounts. The content of your sessions can also be intercepted and examined to see exactly what you're doing.

SSH not only encrypts the passwords used, it also encrypts your entire session. Thus you can connect to other machines, typing your passwords for those machines, and be confident that no one will be able to sniff your passwords or watch you write a secret e-mail message.

Running SSH

SSH is installed on all mathematics department systems in some form or other. On the Linux systems, you can run SSH by typing ssh. Mac OS X systems also have SSH installed and you can run it from

Because Windows doesn't really use its terminal-like consoles for much by default, you have to download and install an SSH client. We prefer PuTTY, which is free and very functional. It's installed by default on Windows systems we maintain.


Once you have access to an SSH client, you can connect to a departmental machine by typing

ssh username@host

where username is your username on the math machines and host is the machine you want to connect to. (If you're connecting from a machine plugged into the math subnet, you can drop the; if you're in a dorm or another part of campus, you'll need to include that part of the address to make sure you're connecting to the right computer.

PuTTY can be run from the command line, in which case it works just the same, but it also has a graphical-user interface which presents various text boxes to type your information into.

When you press Return, you should see a Password: prompt. Type your math-department Linux password.

sshing to a Host for the First Time

When you connect to a host that you've never connected to before, you should see something like the following:

me@crispo (~): ssh organdy
The authenticity of host 'organdy (' can't be established.
RSA key fingerprint is a6:08:31:d4:c7:d5:70:dd:ce:9a:64:73:a3:fb:97:37.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'organdy,' (RSA) to the list of known hosts.
me@organdy's password:
me@organdy (~):

The ssh program is warning you that it can't ensure that the host you're connecting to really is the host it's claiming to be, because it has never seen this particular host's key before.

The fingerprint ssh shows you is the result of a calculation that converts the actual public key of the host to a unique, more readable, form that you can use to compare with other records. We maintain a list of fingerprints for our systems that you can use to check the validity of your connections to our hosts.

If you tell ssh to continue connecting, the program will cache the host's public key in your ~/.ssh/known_hosts file. If you look in that file, you'll see very long lines similar to

daceyville, ssh-rsa

The comment (the line starting with #) tells you that the following key is from a host called eve, which is running version 1.99 of the SSH protocol, and that the server is running OpenSSH version 3.6.1p2.

The second line is the host's public key. It starts with the name of the host (eve), followed by the number of bits in the host key (1024), then (35), and last the key itself.

The next time you connect to a host whose key has been cached, you will see something similar to

me@crispo (~): ssh organdy
me@organdy's password:
me@organdy (~):

More Sophisticated Uses of SSH

SSH can do more than just give you an interactive terminal session, and it can also allow you to connect without typing your password over and over again.

Running Commands

The -f allows you to run a command noninteractively—that is, if you wanted to know how many people were logged in on organdy, you might run

ssh -f me@organdy w

which would ask you for your password and then give you the same output you would have seen if you had connected and then typed w at a prompt on organdy.

X Forwarding

If you're running an X Window server on your machine (typical for Linux systems; using the on Mac OS X; or using an application such as XSpeed or the X server that comes with CygWin on Windows), you can run programs on remote machines and have their windows appear on your local display.

Depending on how your system and account are configured, X forwarding may or may not be active by default. One way to check is to ssh to the remote system, then type echo $DISPLAY. If you see something similar to localhost:10.0, X forwarding is active, and you should be able to run a program that creates an X window and have that window appear on your machine.

If DISPLAY is empty, you may need to make sure that your X server is running and that you have a DISPLAY environment variable set on your local machine. Verify that it's working by running an X program on your local machine. (You will have to log out of and back into the remote machine.)

If you're still not seeing a DISPLAY environment variable on the remote machine, you may need to specify the -X flag to your ssh command line to turn on X forwarding for that connection. (You can turn it on permanently by editing the ssh_config file in /etc; you'll probably need to have root privileges to do so. On Windows, there's probably a setting you can tweak in your GUI client to turn forwarding on.)

SSH Keys

SSH uses a form of public-key encryption; every host has a private key that it keeps to itself, and a public key that it shares with the world. When an SSH client connects to an SSH server, they do a dance, exchanging public keys and generating a session key (which is unique to that connection) that they use to do their communication.

A cool side-effect of this functionality is that it is possible to create your own public and private keys, and use those to control connections between machines.

Creating a Key

You create a key using the ssh-keygen command. It takes several arguments, including (most commonly) the size of the key (in bits), and the type of encryption the key should use. A typical use would look like the following:

[me@daceyville ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/students/hmc_2020/me/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): ***************
Enter same passphrase again: ***************
Your identification has been saved in /home/students/hmc_2020/me/.ssh/id_rsa.
Your public key has been saved in /home/students/hmc_2020/me/.ssh/
The key fingerprint is:

(Note that the *** do not appear when you type your passphrase; the terminal doesn't show anything; they've been added in this example to indicate that the passphrase should never be left blank.)

You now have a private key, id_rsa, and a public key, You should keep your private key private—don't give a copy to anyone, or change the permissions on the file so that anyone other than you can read it. (That is, the permissions on your private key, at least, should be 600—you can read and write the file, but no one else can; your ~/.ssh directory will need to be set to 700.)

The public key, on the other hand, is meant to be used on other systems that you want to connect to using your SSH key. If you copy it to another system and add it to a file called ~/.ssh/authorized_keys, you can use your SSH key to connect (typing your passphrase when it's requested) rather than your password. (The authorized_keys file also needs to have read-write permissions only for you.)

Using the SSH Agent

Where this method gets cool is with the use of the SSH agent program, which caches your passphrase and allows you to connect without having to type your password or passphrase again and again.

The SSH agent program is started by typing

[me@daceyville ~]$ eval `ssh-agent`
Agent pid 28727
[me@daceyville ~]$ ssh-add
Enter passphrase for /home/students/hmc_2020/me/.ssh/id_rsa: 
Identity added: /home/students/hmc_2020/me/.ssh/id_rsa (/home/students/hmc_2020/me/.ssh/id_rsa)

You can now connect to systems that have your public key in an authorized_keys file by simply typing ssh me@host.

You will be able to use the agent until you log out. If you want to remove your keys from the agent,

ssh-add -D

will remove all identities from the agent. You can also use the -x flag to set a temporary password for using the agent, and the -X flag to turn that password off.

ssh-agent -k will kill the agent.

Graphical User Interfaces and SSH Agents

Most modern Linuxes start an SSH agent process as part of the X startup sequence, so if you're logged in at the console of a Linux machine, you probably already have an SSH agent waiting for you to add keys. And most modern systems will also have a graphical prompt for you to add keys (often set up so that just typing ssh me@host will cause the prompt to appear so you can unlock your key and add it to the agent.

Mac OS X also includes an SSH agent with graphical prompts, and you can use the Mac OS X keychain to record and provide your passphrase, so that you can type a different password (or no password at all, if your keychain is already unlocked) rather than your passphrase.

Risks of Using SSH Agent and SSH Keys

When you're running the SSH agent, anyone who can get access to your terminal can connect to any machine that you have access to with the SSH keys loaded into the agent as you. Thus they can do anything that you can do on those machines, from sending e-mail to deleting all of your files. Therefore, it is very important to lock your machine when you walk away, or at least lock the SSH agent program with a passphrase.

You can also set a time after which your keys will be unloaded by specifying the -t flag to the ssh-agent command. This flag takes an argument that is the time in seconds until keys are unloaded from the agent (i.e., -t 60 means your key will work for a minute; -t 3600 for an hour; etc.). The ssh-add also has a -t flag that works the same way. If you specify one value for ssh-agent and a different value when you load your keys with ssh-add, the value specified for ssh-add will take precedence.

Empty Passphrases

You may have noticed when you created your SSH key that ssh-keygen mentioned that you could leave the passphrase “empty for no passphrase”. Don't. While not having a passphrase on your SSH key makes it work like you were running the SSH agent all the time, it also means that there is no way to protect your key from being used by anyone who gets access to your terminal. Use the SSH agent instead. Sacrificing all security for convenience is stupid.

Copying Files and Directories

OpenSSH includes the scp and sftp commands for moving files between systems. On the Mac, you can also run Fugu, a graphical SCP/SFTP client. On Windows, you have the command-line scp and sftp included with PuTTY, but you can also run WinSCP, a graphical client similar to Fugu.

The command line scp works pretty much just like the standard cp command, except that its source and destination parameters look a bit different.

For example, to copy a single file from your local machine to your home directory on a remote host, you could run

linux% scp foo.txt me@remotehost:

To copy a file from the remote host to your local system, you might run

linux% scp me@remotehost:bar.txt .

To copy multiple files, you can use shell wildcards (quoted if you use them in the remote path so they don't expand locally), or, if you're copying a whole directory, you could do something like

linux% scp -r me@remotehost:/tmp/myproject ~/work/projects/math-121-ass1

(Notice how I tossed in scp's ability to change the names of the things you copy, as well as putting it in a different directory on the local host?

The main downside of scp is that you have to know the whole path and filename(s) of the material you want to transfer when you're putting together the command line. sftp works like an old-fashion FTP client, and allows you to connect to a remote host, cd around in its filesystem, and get or put one or more files.

What Hosts Support SSH?

All of our Linux systems support SSH connections. You will not be able to connect to the servers, but any “public” workstation (such as the machines in the scientific-computing lab) will accept connections from student, faculty, and staff accounts. is a special DNS alias that allows you to connect to machines in the scientific-computing lab. It works by having a list of machines, and giving them out one-by-one to requestors, and starting again at the top of that list when it's reached the end.

SSH Warnings

Because the same name is associated with multiple machines, each with their own host key, you may see a message such as

   % ssh
   Someone could be eavesdropping on you right now (man-in-the-middle
   It is also possible that the RSA host key has just been changed.
   The fingerprint for the RSA key sent by the remote host is
   Please contact your system administrator.
   Add correct host key in /home/students/you/.ssh/known_hosts to get rid
   of this message.
   Offending key in /home/students/you/.ssh/known_hosts:47
   RSA host key for has changed and you have
   requested strict checking.
   Host key verification failed.

You can verify that the fingerprint of the host corresponds to one of our machines by checking the fingerprint list. Because of the way that the Windows clients store host keys (in the registry), that's about all you can do. If you don't want to see the warning, you'll have to try connecting directly to a machine you're allowed to log into.

The key-caching system used on Linux and Unix machines (including Mac OS X), allows you to store multiple copies of keys with different names. So, for example, you can use the hostname that you found by checking the fingerprint list to find the matching key in your ~/.ssh/known_hosts file. You can then make a copy of that key and change the hostname to shell or

To make your life easier, you can add the contents of this known_hosts-for-shell (GPG signature) file to your ~/.ssh/known_hosts file to get them all in one fell swoop.