Computer Laboratory

SSH access to the Computer Laboratory

This page gives first an overview and then details of using ssh to connect to the Computer Laboratory systems from the Internet. For an overview of external access see Remote Access to Lab Systems.

It is important that you understand the notions of keys and user and host authentication before you try to set up an ssh connection from outside the Laboratory. If you don't want to read this overview then go straight to the summary and see if you understand that if not, then you will probably need to read this or some other description before you can make any progress.


Internet traffic is neither private nor secure. Data sent from one system to another across the internet can be forged and is subject to intrusion and alteration. To make this more difficult the data can be encrypted and connections between machines can be authenticated using cryptography. This is the purpose of ssh. In order to be able to use ssh properly it is necessary to have some understanding of how it works. This is not as complicated as it may at first seem.

Throughout this page we use the term ssh as a generic name for the client program implementing the SSH protocol. On Unix/Linux machines the program is most likely OpenSSH and on Windows machines it is typically PuTTY.


Ssh encrypts data passed between hosts using a session key. This is a large number known only to the two hosts in question. The session key is different for each session and is agreed upon at the start of the session using a mathematical protocol which it is believed does not expose the number to anyone intercepting this exchange between the hosts. The session key is then used to encrypt the subsequent data passed between the two hosts. This entire process is almost transparent to the user of the ssh program.

The net result of this is that the information transferred over the ssh connection cannot be intercepted and altered. It is still vulnerable in at least two different ways though: Firstly, the machine from which the connection is initiated could have been compromised and could be revealing the communications where they enter and/or leave the encrypted stream. Thus for example, a user's password for logging in to the remote host could be revealed by a program 'watching' keypresses. Secondly the remote host could in fact be a different machine - one controlled by the attacker - which is masquerading as the remote host the user thinks they are communicating with. That machine could then relay traffic to and from the real remote host and the user would be none the wiser. This is known as a 'man in the middle' attack.

For these reasons ssh provides host and user authentication facilities, as well as encryption.

Host authentication

Host authentication is accomplished using a private/public key pair for each host to which ssh connections can be made. Once the above session key has been established, the remote host uses its private host key to digitally sign the session key. It then sends the signature along with its public key to the ssh program which verifies the signature and then checks to see if the host's public key exists in the list of known hosts. If it does not then it generates a warning to the effect that the remote host is not known, or has had its key changed. Along with the warning the ssh program will print a fingerprint of the host's public key. This gives the user the opportunity to verify that the public key is indeed that of the remote host he or she is attempting to establish a connection to. The host key can be checked by looking it up in a database or by verifying over the telephone or via some other relatively secure channel.

User authentication

In addition to authenticating the remote host, ssh can assist in authenticating users. This is done using OTPW, kerberos ('gssapi-with-mic'), or in a similar way to host authentication, using a private/public key pair for the user. Before accepting an ssh connection from a remote user, a host can verify that the user is in possession of a private key without the user revealing the key itself. This is done by ssh using the user's private key to digitally sign the session key. The signature is then passed to the remote host and verified against a copy of the user's public key held in the user's home directory in ~/.ssh/authorized_keys, or a cached copy. Thus, having made their public key available to a given host, a user can authenticate themselves from anywhere on the Internet where they have a copy of the corresponding private key, so long as the ssh server can access the file holding the public key.

Obviously the veracity of the authentication depends entirely on the private key being kept secret: if the private key falls into the wrong hands then authentication is compromised. So private keys should in turn be secured and the means to do this is by protecting them with a passphrase. This is a secret which is known only to the owner of the private key. Before ssh can use the private key to authenticate the user with a host it must decrypt it using the passphrase entered by the user.

A given public/private key pair should ideally only be used to connect from one host machine (or in the case of a managed network where a number of machines share common home directories, from that network of machines). The list of keys that are valid for connecting to Computer Lab machines are stored in each person's ~/.ssh/authorized_keys file (here ~/ is a shell abbreviation for the home directory).

Note that in the above, the user's Unix password is no longer required for login. Although ssh can be configured to use the Unix password for authentication this mode is specifically disabled for ssh access to Computer Lab machines.

Multiple user key pairs

Since private keys can be compromised, and the location from which they are used may be different, it is a good idea to have one key pair for each system from which ssh connections are made. In the event that a compromise is suspected the key can be replaced with minimal disruption.

Note that private keys should all have significantly different passphrases. If they do not then one of purposes of using multiple private keys is defeated. Note that brute force attacks on the passphrase can be run on the files to find the passphrase, so they should be strong.

To minimise the exposure of the private key it is best to generate it on the machine from which it will be used. Then the associated public key can be transferred to the remote host and installed there. The private key should not be transferred off the machine. When a public key is registered for use in authentication, the set of DNS names or IP addresses from which that key is valid should be specified in ~/.ssh/authorized_keys (see "man sshd" for the format of the file). Each key should be prefixed with a 'from=' restriction indicating the hosts from which that key can be used. This should be the most restrictive list possible: ideally just the address of a single host. However, in many cases this may include a wildcard to indicate a range of hosts. For connections from machine in the Lab this may be "*" so that any machine may be used. For home ISP connections, the IP address and hence DNS name, is dynamic, so may need to be something like "*". Some ISPs do not register their addresses correctly, in which case the IP address may need to be used instead. To see what name or address is actually used, login and use "last -a | more" (DNS names) or "last -ai | more" (IP addresses) to see whence you are connected.

Laptops and similar mobile devices may be connected from several places, e.g. in the lab, in college and at home. The list of possible locations should be put in as a comma separated list. Try to restrict the locations as much as possible, e.g. using ",*" rather than "*".

When travelling, the location may be unknown in advance, so append another line with the same key, with a single "global" wild card: 'from="*.*"' for any IPv4 address, 'from="::/0"' for any IPv6 address, or 'from="*"' for any IPv4 or IPv6 address, to indicate that some thought has gone into it, and that "anywhere" really is required. There should only be the one wildcard location given, but multiple lines can use the same user ssh key. The script /usr/groups/admin/cmds/ checks for "acceptable" lines (look syntactically plausible, and have suitable 'from=' restrictions), and if the line is not the first one in the file, and the file has been updated recently (e.g. due to going on a trip) it 'accepts' such an entry.
It also notes the string "laptop" in the line (typically at the comment at the end, after the long string which is the key itself) of a line other than the first in the file (which must be a normal valid key) as an indication that it is for a mobile device from which CRACKers are unlikely to manage to get the private key without the user knowing (i.e. stealing the device).

A cron job runs the checker script to look for "unacceptable" lines, sending warning emails to the user, and if the problem is not fixed, it renames the file, causing ssh user key authentication to stop working.

A sample file (with "..." for the bulk of the actual key) might be

from="*"               ssh-rsa A...dLOE=
from="*" ssh-rsa A...pNJw= giles@home-pc
from=""           ssh-rsa A...aP6f= rsa-key-20081029 college
from="*," ssh-rsa A...dxyQ= gsm@ra4
#from="*.*"                         ssh-rsa A...dxyQ= gsm@ra4 on a trip using IPv4
from="*"                            ssh-rsa A...3SMQ= giles@pda laptop

for a set of keys

  • available to all machines in the department for internal Lab access
  • on a cable modem router on a home PC "home-pc"
  • on a college Windows PC, generated 29th October 2008
  • on a laptop used in the Lab, and using Lapwing
  • commented out copy of the same key, which can be uncommented when the laptop is taken on a trip away from Cambridge
  • on a PDA which is carried at all times

Having updated authorized_keys run the checker script /usr/groups/admin/cmds/ to check that it is acceptable (the lines look syntactically plausible, and have suitable 'from=' restrictions)

Update slogin servers

If using a Time Sharing System such as one of the slogin-serv machines or other NFS sec=sys system with cached authorized_keys files (e.g. has a directory /var/spool/ssh/), the local cached copy may take a while to be updated unless "cl-update-authorized-keys" is run to update the local` copy to allow immediate testing. Note that it is important to connect to the same machine (use 'hostname' or 'uname -n' to determine the machine name - slogin-serv is a set of machines). Alternatively (but somewhat slowly), a script can be run to update the slogin-serv machines using the command "cl-onserver --fixsshcache".

Trying to cache the file on machines which do not have cached files (e.g. most user machines and pool machines such as the ACS ones) will fail. ssh access from the internet using user ssh keys requires there to be a valid kerberos ticke ticket on the machine, so in general will not work..

Access via VPN

With the provision of the CL VPN, users may well find it simplest to use it to ssh into the Lab Time Sharing System. Place the raw public key in $HOME/.ssh/cl-vpn/*.pub, with no restrictions on it, e.g.

ssh-rsa A...dLOE=

and the system will arrange for it to be included in authorized_keys on the slogin servers at the next slogin server update.

ssh-agent programs

Entering passphrases each time a new session is established can become tedious so there are various ssh-agent programs which cache decrypted private keys for subsequent use. This increases the exposure of the keys but only in a limited way that in most situations is an acceptable risk. The agent program on Linux systems is called ssh-agent. There is a program called Pageant that is part of the PuTTY suite for Windows. Details on the use of agent programs are given on the pages that describe the ssh clients for Unix/Linux and Windows systems.


The ssh client program encrypts communications to and from a remote host (the Computer Lab machines in this case). It also authenticates remote hosts by checking the hosts' public key against a list of known hosts' keys, and authenticates users using the OTPW password, kerberos ticket, or the user's private key.

Users should have multiple public/private key pairs, each used for connecting from different sets of hosts. The user's private keys are kept only on the hosts from which the connection is made and only the public part of the key pair is stored on the remote host. The list of public keys that can be used for authentication (and the names of the hosts they can be used from) is stored in the user's ~/.ssh/authorized_keys file on the remote host.

Private keys must be protected with a passphrase to be entered before the key can be used for authentication. There are various ssh-agent type programs that store decrypted private keys in a cache for re-use without requiring the pass-phrase to be entered again.

Ssh clients

On Unix and Linux hosts the normal client is OpenSSH. On Windows the PuTTY client is freely available. The following pages provided detailed instructions on how to set up the clients and keys for access to Computer Lab hosts.

Note that all of these pages assume you understand everything in the summary section above.

Host keys

Many machines, including the lab slogin machines, should have their keys available in the DNS as SSHFP RRs (see "host -t sshfp"). If you have a DNSSEC enable resolver which you can trust, you can save the information manually, or use "ssh -oVerifyHostKeyDNS=yes" to login from a machine which uses a resolver which does not hve an authorative copy of teh zone file.

Fingerprinting host keys

You can take a copy (on paper or otherwise) of the key fingerprints rather than the host keys themselves. Then on making the first connection to a remote host you can check the fingerprint of the key before accepting the connection. If you accept then ssh will add the host's key to your known_hosts file automatically.

To get the key fingerprints of the machines on a Lab Linux machine try running a command such as

cl-ssh-keyfinger slogin
On the machine, they can be generated using
for f in /etc/ssh/ssh_host_*.pub; do ssh-keygen -lf $f; done

The fingerprints for login-serv as of July 2014 are

 256 fb:db:72:ad:04:26:5c:39:a8:38:eb:6c:f5:bb:14:5c  (ECDSA)
 256 e8:4b:54:e9:cf:cb:ef:4f:83:f0:ad:26:08:d4:4b:b5  (ED25519)
1024 2c:02:de:5c:13:38:c9:39:86:24:a8:71:91:d5:20:7a  (RSA1)
1024 84:b2:e7:b9:3b:e4:cc:ca:d5:0a:08:5a:c2:89:e8:99  (RSA)
1024 08:9e:51:6a:71:1f:09:88:1e:38:aa:30:d7:69:e4:b8  (DSA)

Note that you should trust the above fingerprints only in so far as you trust the integrity of the computer you are using to view this page and the intervening network connection(s). It is quite possible for web pages like this one to be 'spoofed'.

Accessing user WorkStations from outside

Most user WorkStatiions use NFS sec=krb5 so the sshd cannot check the user's key as it doesn't have access to the authorisation file. Consider using the slogin-serv machines instead, or use one of the various techniques to login.