SSH access to the Computer Laboratory
This page gives an overview of using ssh to connect to the Computer Laboratory systems. 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; on Windows machines, it is typically PuTTY.
Internet traffic is neither private nor secure. To prevent intrusions or alterations, the data can be encrypted and connections between machines can be authenticated using cryptography.
Ssh encrypts data passed between hosts (e.g. a local user and a remote host) using a session key, which 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. The session key is then used to encrypt the subsequent data passed between the two hosts. The net result of this is that the information transferred over the ssh connection cannot be intercepted and altered.
Despite that, the data is still vulnerable in at least two different ways. Firstly, the machine from which the connection is initiated could have been compromised — for example, a user's password for logging in to the remote host could be revealed by a keylogger. Secondly, the remote host could in fact be a different machine masquerading as the remote host. That machine could then capture or alter the data relayed to and from the real remote host without the user's knowledge — 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 is accomplished using a private/public key pair to which ssh connections can be made. Once the session key has been established (see above), the remote host uses its private host key to digitally sign the session key. The remote host then sends the signature along with its public key to the ssh program which verifies the signature and checks to see if the host's public key exists in the list of known hosts. If it does not, the ssh program generates a warning 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 the user is attempting to establish a connection to. The host key can be checked by looking it up through a secure channel.
In addition to authenticating the remote host, ssh can assist in authenticating users. This is done using one-time passwords, Kerberos protocol, or using a private/public key pair for the user that works in a same way as host authentication.
The security of the authentication depends entirely on keeping the private key secret. If the private key falls into the wrong hands, authentication is compromised, so private keys are generally secured with a passphrase — a phrase which is known only to the owner of the private key. Before ssh can use the private key to authenticate the user, it must first decrypt the key using the passphrase entered by the user.
Each public/private key pair should 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 on the remote host (where ~/ is a shell abbreviation for the home directory).
Multiple user key pairs
Since private keys can be compromised, 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. All private keys should have significantly different passphrases. Passphrases should also be fairly strong, as they are otherwise easily cracked by brute force attacks. There is no maximum character limit for a passphrase, so you can make it as long as you wish.
To minimise the exposure of the private key, it is best to generate it on the machine from which it will be used and never transfer it off that machine. The associated public key can then be transferred to the remote host and installed there.
The ssh client program encrypts communications to and from a remote host (in this case the Computer Lab machines). It also authenticates remote hosts by checking the hosts' public key against a list of known hosts' keys, and authenticates users using the one-time password, kerberos ticket, or the user's private key.
Users should have multiple public/private key pairs for 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 passphrase to be entered again.