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 Terminal.app.
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.
Connecting
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 .math.hmc.edu; 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 (134.173.34.25)' 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,134.173.34.25' (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,134.173.34.142 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsrA6eT1cHXkxNJ7CBcEtptWsB/9Ybt9wk8LrEhqlhG3mNzGScfhluBlzjTnOlvyCAm/i+HFpWVulFqScw7VdkGK51QyGuC3pjaKJ6PAAcmgd1qBJi33WicKZYhRfRtwhfCMmuXvpLzGAO/Gn/oagRcGyGdAkBZTfA39zxS4mCGiP2L/XtXdCrt5Kh2EQYL7Trei6EuNORuj+ZhweKBAXGQ2ah59LNJ1VMZi8EHWGhsoCwuVIaerH9X+wil9gxrkqdwLzb5RhXrqkHYey4UkeIloqqQycANsN9JcFIV4EyGRi0HBQBO0ky6YF/NWoIYCJDg7IT4QYLuU0IQ9ym95m/Q==
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 X11.app 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/id_rsa.pub. The key fingerprint is: e1:04:8e:e6:30:4d:a4:ec:23:72:87:8a:37:63:43:d5 me@daceyville.math.hmc.edu
(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, id_rsa.pub. 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.
shell.math.hmc.edu 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 organdy.math.hmc.edu @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! 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 a6:08:31:d4:c7:d5:70:dd:ce:9a:64:73:a3:fb:97:37. 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 somehost.math.hmc.edu 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
shell.math.hmc.edu.
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.
