Secure Shell in Brief

In order to eliminate our vulnerability to the network being sniffed for passwords, we implement a policy of eliminating services for which clients communicate passwords in clear text. Consequently, the Linux workstations only allow remote (including the rest of the campus) access for log-in or file transfer from clients which support the SSH protocol. With SSH, the entire session, not just the initial password (or passphrase) exchange, is encrypted.

Remotely logging in to, and executing remote commands on, Linux machines in The School requires the use of a Secure Shell client. Security comes from verifying that the remote host is the host it claims to be, and by encrypting network traffic during connections (so there is little risk in using clear text passwords if applications don't do any better themselves).

Secure Shell is the only means of accessing the Linux machines from outside The School, including from central NUIT. Cluster machines are on a private University network and can't be accessed directly from off campus. Linux.cs, however, is on a public network and can.

Accessing a service on a Linux machine may be achieved from outside The School by using Secure Shell's port forwarding feature. Direct access is possible from on campus, but indirect access via linux.cs, for instance, will be necessary if the service is on machine that can't be reached directly.

The central NUIT Unix servers provide SSH clients and run SSH servers, so SSH access is possible in both directions, and central NUIT Windows home filespace (on the tower servers) is accessible by Secure FTP (SFTP).

Secure Shell in Detail


There are two versions of the SSH protocol. Version 1 is deprecated, so the School's servers, although capable of supporting both protocols, have been configured to accept only protocol 2 connections.

You should be aware that if you use SSH to attempt to access a remote machine which does not support the protocol, the session may revert to rlogin/rsh/rcp behaviour, i.e. it will be an insecure session; you will probably be warned that that is happening.


In order that clients can trust the hosts they are connecting to, they refer to lists of host keys for known hosts. For successful communication to take place, the host key of the remote machine must match that stored for it by the client. A mismatch could simply indicate that the remote host's key had changed, e.g. because the key had not been preserved across upgrades of the software, or it could mean that a man in the middle attack was in progress. For example, mismatching keys results in the following form of output on the Linux machines

The DSA host key for linux.cs has changed,
and the key for the according IP address
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/njkw/.ssh/known_hosts:4
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the DSA host key has just been changed.
The fingerprint for the DSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/njkw/.ssh/known_hosts to get rid of this message.
Offending key in /home/njkw/.ssh/known_hosts:5
DSA host key for linux.cs has changed and you have requested strict checking.
Host key verification failed.

/!\ It is important that you don't ignore such warnings, but report them.

Obviously the host keys of remote hosts must get to the client machine somehow. In some cases, particularly on the Linux machines, the host keys of other Linux machines are already known and stored centrally, and no verification is required. Otherwise, the first time you connect to a host, e.g. to linux.cs from home, you may be required to explictly accept the key. For example, from a Linux client

The authenticity of host 'linux.cs (' can't be established.
DSA key fingerprint is 01:b6:1d:83:04:ad:20:1c:be:ad:82:e4:80:ce:ca:45.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'linux.cs' (DSA) to the list of known hosts.

Keys are added to the file $HOME/.ssh/known_hosts. The mill cluster machines all share the same host key - an entry beginning:


will prevent you being asked to accept a key whenever you visit a new mill.

Secure Shell Clients

Free Secure Shell clients are available for the three main operating systems should you wish to access Linux - normally linux.cs - from a private machine.


If your private machine runs Linux then the OpenSSH package may already be installed; if not, it will likely be possible to install it from the distribution media.

The Unix version of PuTTY is another possible client. An advantage may be that it may be easier to set up profiles, or as it calls them, sessions, using its graphical configuration interface.


PuTTY and the graphical file transfer client WinSCP are both available from the CS Portable Apps on CMD machines.

It is possible to download individual PuTTY clients or all of them bundled together. If you download the latter you will have everything needed to use public key authentication. However, there is some overlap in the programs that these downloads provide. Some WinSCP downloads could include some PuTTY clients you already have. WinSCP attempts to be independent of PuTTY, and also provides a bundle including the clients required for employing public key authentication.

Mac OS X

Mac OS X provides OpenSSH. Fugu, an SSH, SCP and SFTP frontend is available.


The Secure Shell servers on the School's Linux machines support the Keyboard Interactive, Public Key and Hostbased authentication methods. Password authentication is not supported.

Password authentication implies authentication using passwords from the local Linux password file. However, the Linux machines have been configured to perform authentication using campus passwords, and that determines the use of the Keyboard Interactive method.

Keyboard Interactive

This method may also be referred to as keyboard-interactive. It is attempted automatically by OpenSSH and PuTTY, usually after other methods have been attempted and failed, but has to be selected explicitly by the Windows client.

Public Key

The Public Key authentication method requires a little bit of setting up, but once done, has advantages. It involves the use of a pair (public and private) of keys, generated by you using your client (or an associated program). The private key stays on the client machine (to be read by clients); the public key has to be added to the file .ssh/authorized_keys in your Linux home directory. As your home directory is shared across machines installing the public key per key pair only has to be done once. Furthermore, you can use the same private key on different machines, and hence only need one entry in authorized_keys.

The use of an authentication agent is beneficial in conjunction with public key authentication. The agent program is typically started early in a session and populated with keys; the user is required to authenticate keys at the time of adding them. Thereafter, clients check for the existence of an agent, and attempts to authenticate using the stored keys are performed before resorting to interactive methods. The process markedly speeds up connection, and the irritation of continually having to enter a password or passphrase is avoided.

Key generation and installation, and the authentication agent are described separately.

Port Forwarding (Tunnelling)

Direct external connections to ports other than the SSH port (22) are not allowed, and linux.cs is the only host that can be connected to from outside the School. To connect to a service running on a Linux workstation from outside Computing Science it is necessary to employ port forwarding. With port forwarding, the traffic between ports on the local and remote machines is transmitted over a secure SSH channel. In practice, if a user wishes to run application A connecting from a non-Computing Science campus host to port R on remote machine S, then they request SSH to forward some arbitrary port P on the local host to port R on S and then have A connect to port P.

A special case of port forwarding is X11 tunnelling in which the traffic from X clients on the remote machine is routed via the ssh connection to the host. The feature is either on by default, or easily enabled, e.g. by the addition of an option -X on the command line, or by the tick of a box in graphical clients. A major advantage of the mechanism is that it reduces the setting of the X DISPLAY variable on the remote machine to not having to do anything; the display of remote X clients just works. However, it is only possible if enabled in the Secure Shell server on the remote host, which is true of Linux machines in The School.

If you wish to run X programs after logging in to Linux from Windows you need to have X11 tunnelling enabled and the eXceed X server running (Programs -> Communications & Internet -> Exceed -> Exceed). Shortcuts named Linux.cs, for, and Linux.cs(PuTTY) under Programs -> Departmental Software -> Computing Science -> Utilities start the corresponding SSH client (with Keyboard Interactive as the default authentication method and X11 tunnelling in effect) and the eXceed server, so that as soon as you have authenticated you are in a position to run X applications on linux.cs.


With OpenSSH, the above scenario would be set up using the following command

ssh -L P:localhost:R  S

The name between the colons, preceding R, is the name of the host to be contacted on port R, which need not be the same as S. However, when it is, and as name resolution is carried out on S, it should be specified as localhost.

An example where the host running the service on port R is not the same as S might be accessing the School mysql server from off campus. The GUI client My SQL Workbench will set up a ssh tunnel for you if you select the Standard TCP over SSH connection method (see Databases), but to use the command line mysql client you need to set up the tunnel via ssh directly e.g.

ssh -L3306:homepages.cs:3306

Here, authenticatication is on linux.cs, which is in the domain, and hence permitted to access the mysql server. The SSH daemon on linux.cs arranges for traffic arriving from the port 3306. (It is normal to use the same number for the port being forwarded as that for the port being forwarded to. However, on Unix and Unix-like OSes, such as Linux, access to the ports numbered less than 1024 is restricted to the root user, so that may not always be possible).

When Secure Shell is being used for its port forwarding functionality it is usually the case that a terminal connection to the Secure Shell server machine is not required., It can be suppressed by using the -N option.


/!\ These are old examples (i.e. ports and hosts) but the principle still holds

Connection -> SSH -> Tunnels is selected in the PuTTY Configuration window in order to set up port forwardings.

X11 Forwarding is the default, and is shown enabled. The window shows local port 1113 having been set up to be forwarded to port 113 on host news by the host (which is specified on the Session screen) to be connected to. An assumption is that news is in the same domain as that host.

The window also shows local port 1521 being set up to be fowarded to port 1521 on ludgate so that an [:Databases:Oracle] database can be accessed from off campus using JDBC. The forwarding won't take effect until it is added by clicking the Add button.

[!] If the tunnel cannot be created for some reason, PuTTY does not warn you, but it does add details to its event log. You can see the event log from PuTTY's extensions to its window menu i.e. click on the little PuTTY icon at the top left of the open PuTTY window, or shift right click on the PuTTY icon in the task bar (no shift pre-Windows 7).

(!) You can experiment with making tunnels after connecting to the tunneling host via Change Settings ... (in the PuTTY window menu extensions (as above).

On Windows, the procedure for forwarding ports is to select Outgoing under Tunneling from Edit -> Settings... in the client and fill in the details as required. The following window shows local port 1113 being requested to be forwarded to port 113 by the host, e.g. linux.cs, to which the connect is made. You would do this to be able to read news from off campus; linux.cs, being on campus, is permitted to access the news server machine news. It also shows that X11 tunnelling has been enabled.

The following window, popped up by clicking the Add... button, shows local port 1521 in the process of being set up to be forwarded to port 1521 on ludgate for the purpose of accessing an Oracle database from off campus using JDBC.

Note that tunnels are defined in a connection profile. You can choose to do this in the default profile which applies to all new connections made with Quick Connect or in a specific profile. You don't have to save the modified profile, but it may be helpful if you intend to use it regularly.


Open the Create Tunnel dialog by selecting "ssh:New ssh Tunnel" or pressing command T. This example sets up a tunnel to wiki.cs. This would then be accessed by going to http://localhost:8080/

Fugu doesn't currently do X11 port forwarding. Use open ssh, either from an xterm or a terminal window. If you use a terminal window, then make sure you set DISPLAY first. xterm has this set already so you can omit the first 2 lines of the following:

export DISPLAY
ssh -X linux.cs

Configuring Clients



A collection of commonly-used settings can be saved in a Session.

  • To create a Session: open the main PuTTY Configuration window (i.e. launch PuTTY or select New Session... after right clicking on a terminal window titlebar), fill in any settings eg Host Name, then enter a name in the Saved Sessions field and click Save. The name will appear in the list underneath.
  • To edit a Session: select its name in the session list and click Load, make some changes, then click Save.
  • A Session can be modified before being used. When ready to use it, click Open, or double click on session name.
  • Settings can be changed on the fly after logging in by right-clicking on the terminal window's title bar and selecting Change Settings... from the menu.
  • From here you can also create or update a session: in category Session select a session name or enter a new one before clicking Save.
  • Recently used sessions appear in a Windows 7 (right click on the PuTTy icon in the taskbar to display its jumplist) jumplist along with tasks to run PuTTYgen and Pageant

Useful Settings

Auto-login username: Found in the Connection -> Data screen. Using this feature means that you won't be prompted for your username.

Window size: Found in Window.

Window colours: Found in Window -> Colours. If you prefer black on white, select Default Foreground and change each of the Red, Green and Blue fields to 0, select Default Background and change each of its values to 255, then click Apply. The Modify button is for creating a custom colour from a palette.

A Poor Man's VPN (or Better than VPN?)

When off campus, if you would like to get at on-campus websites that are inaccessible to off-campus hosts, or to off-campus sites that only allow access from on-campus hosts, then instead of the trouble of setting up a VPN connection you can use SSH dynamic port forwarding with SOCKS to achieve this. All you need to do is:

  1. log in to linux.cs using a ssh command such as ssh -D 1080 or plink -D 1080 using putty's command line utility on Windows, or set up a putty session to linux.cs and in Connection->SSH->Tunnels set Source port to 1080 and enable Dynamic before hitting Add.
  2. Set your browser's web proxy to use a socks 5 proxy to localhost:1080 - FoxyProxy, available for IE, Firefox and Chrome, is a convenient way of switching your proxy settings.
  3. Go to a site which reveals your IP address such as - if all is working it will say i.e. the address of AKA
  4. You might like to try some different options to the connection command - eg -N which does the port forwarding without give a remote shell, and -C to enable compression (both options work in ssh and plink).