= 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 [[http://www3.imperial.ac.uk/ict/services/securitynetworkdatacentreandtelephonyservices/collegenetwork/networkconnections/vpnconnection|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 [[https://www.doc.ic.ac.uk/csg-old/windows/intro.html#putty|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 @shell1.doc.ic.ac.uk}}}, where '' 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 [[guides/file-storage/scp|scp]] to grab a copy of the file, edit it locally, and [[guides/file-storage/scp|scp]] it back again. [[guides/file-storage/scp|Scp]] should be part of OpenSSH on Linux; you can get it for Windows as part of the [[http://www.chiark.greenend.org.uk/~sgtatham/putty/|PuTTY suite]] but there's no pretty GUI to help you use it. [[http://x.cygwin.com/|Cygwin]] is also another possibility as it provides Linux API support in Windows as well as X/SSH capabilities. The [[http://sourceforge.net/projects/xming/|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 [[http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html|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 [[guides/remoteaccess/vpn#Section7|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 [[guides/remoteaccess/vpn#Section8|here]]) whereas an ssh tunnel does.