DoC Computing Support Group

Your search query "linkto%3A%22guides%2Fremoteaccess%2Fssh%22" didn't return any results. Please change some terms and refer to HelpOnSearching for more information.
(!) Consider performing a full-text search with your search terms.

Clear message

Secure Shell (ssh)

Secure shell ('ssh') is a network protocol allowing secure, remote machine access. 'ssh' also refers to applications that allow you to connect using this network protocol. In order to connect, the remote machine (the server or DoC machine) must be running a secure shell daemon/server; Linux and OS X Macintoshes can readily do so while Windows machines require a third-party application.

The local machine (the client or your home machine) must be running a secure shell client; ssh client implementations are freely available for all major platforms (please see below).

You can ssh to the following five DoC Linux servers from off-site (that is, outside the college network):

  • shell1.doc.ic.ac.uk

  • shell2.doc.ic.ac.uk

  • shell3.doc.ic.ac.uk

  • shell4.doc.ic.ac.uk and

  • svnuser.doc.ic.ac.uk (for version control access only, please).

You may ssh to any other DoC machine either:

  • in two hops (via a shell server first) or

  • by first connecting to the College VPN and then ssh'ing directly to your chosen DoC machine.

Long running jobs (that is, over a day, and with very large ram requirements) should run on batch1.doc.ic.ac.uk or batch2.doc.ic.ac.uk.

If your home machine runs Windows you can use a freeware application called PuTTY. There are some notes on using it and a link to the download location here. Just remember that you need to use the fully qualified hostnames as above, not just shell1 which is only sufficient within DoC.

From a PuTTY window you can run text-mode programs (eg. editors such as Pico or Emacs, or the Pine email client) but you won't be able to run X clients (graphical programs). To do that, you need an X server installed on the machine you are sitting at, and to tell ssh to forward the X protocol data over the connection. The lab Windows machines have Exceed which is an X server for Windows. But Exceed costs money and so do most of the alternatives (but see below), so it's likely you'll have to stick with text logins from Windows. If your home machine runs Linux, you need to make sure OpenSSH is installed. Macintosh OS X has the ssh command available from the terminal by default. Under Linux and OS X, you can run the command: 

ssh shell1.doc.ic.ac.uk

and then enter your DoC user-name and password. You can also write ssh <username>@shell1.doc.ic.ac.uk, where '<username>' is your DoC user-name. In fact, you must do that if the user-name on your client computer differs from your college user-name. In any event, you will then be prompted for your college password.

You can replace shell1 with shell2, shell3 or shell4 in the above example to use one of the other shell servers.

If you are running X Windows at home run and enable both 'X11 forwarding' and 'Agent Forwarding' in your ssh client configuration, the command: 

ssh -Y shell1.doc.ic.ac.uk

will allow you to remotely run graphical programs too, though they may be slow due to unoptimised graphics updates. If you want to edit files, you can use scp to grab a copy of the file, edit it locally, and scp it back again. Scp should be part of OpenSSH on Linux; you can get it for Windows as part of the PuTTY suite but there's no pretty GUI to help you use it.

Cygwin is also another possibility as it provides Linux API support in Windows as well as X/SSH capabilities. The XMing PC X Server may also be worth considering.

Secure Shell Tunneling

Secure shell not only provides the means for securely interacting with a remote machine, it can also be used to enable remote operation of otherwise independent applications. This concept is called ssh tunnelling, since the ssh connection tunnels the network traffic between a remote machine and a local application.

Under Linux and Mac OS X, the syntax for setting up an ssh tunnel is as follows: 

ssh username@remotehost -L localport:remotehost2:remoteport

Under Windows, use Plink: 

plink username@remotehost -L localport:remotehost2:remoteport

Subject to a successful authentication on remotehost, the above command specifies that connections on the ssh client machine (one's 'home' machine) to port localport should be tunnelled (through the SSH connection to remotehost) to port remoteport on remotehost2. Here is a more-concrete example:

Suppose you are outside college and wish to browse an on-line, scholarly resource, access to which is regulated by network address: in other words, you need to be browsing from a DoC computer in order to have access. Rather than fire up a VPN connection, you can set up an SSH tunnel instead: 

ssh username@shell1.doc.ic.ac.uk -L 3128:wwwcache1.ic.ac.uk:3128

The above command specifies that port 3128 on one's local machine should be tunnelled to port 3128 on the college web proxy server. It is then possible to configure one's browser to use '127.0.0.1:3128' (that is, port 3128 on one's local machine) as a proxy server, whereupon all network traffic associated with the browser will be relayed via shell1.doc.ic.ac.uk to wwwcache1.ic.ac.uk in a secure manner.

ssh tunnelling can be used in much the same way as a VPN connection (see here) but is more versatile since it can be immediately deployed on a per-application basis. In addition, the current DoC VPN configuration for OS X does not support encryption (see here) whereas an ssh tunnel does.