ssh (secure shell)

Introduction

ssh, the "secure shell", is a set of programs which provide the facility to log into a remote machine, execute commands on a remote machine, or copy files from one machine to another, in a manner that provides strong authentication and which encrypts any data passing between machines.

Background and Terminology
Using ssh (simply)
Special info for use on the CUED teaching system
Why use ssh?
Reasons not to use ssh?
How ssh works
Using ssh (more advanced)
Administering and installing ssh
Versions and Licensing
Available client software / supported platforms

Background and Terminology

A very useful introduction to the concepts behind this kind of program is provided by RSA Laboratories in their FAQ (Frequently Asked Questions) page . A very brief (and hence imperfect) summary would be to say that with ssh it is possible to communicate between computers in such a way that it is almost impossible for anyone else to either observe what you send, to pretend to be you, or to pretend to be the computer you thought you were communicating with.

If you're worried by the phrase " almost impossible", you should carefully read the RSA Laboratories' FAQ mentioned above. Put simply, all cryptographic tools (such as ssh) attempt to balance the cost to the user (in terms of time taken, processing resources required, and utility) against the cost (in terms of computing resources required) to a possible attacker who wishes to compromise your data and/or communications in a reasonable amount of time. If a theoretical attack on a cryptographic system were to require billions of pounds worth of computing equipment for many months in order to succeed, most people would probably assume that their data was not that important to anyone. (Note that the above is not an estimate of the resources required to break ssh).

Using ssh (simply) on unix systems

PLEASE NOTE that in order to simplify this section, some details have been skipped over, resulting in some minor inaccuracies. These should not be noticeable during trivial use of these programs, but any behaviour that doesn't match with this description should be explained in the section on advanced use. Also, in the examples below, the text "prompt%" is a representation of the command line prompt, and not part of what should be typed.

The simplest use of the ssh programs (slogin, ssh, and scp) is as direct (but more secure) replacements for the traditional unix utilities rlogin, rsh, and rcp.

Given two machines MyMachine (that you're currently using) and RemoteMachine (that you want to do something on) which have both had the ssh package installed, then typing
```
prompt% slogin RemoteMachine
```
will result in you being prompted for a password (assuming that this isn't suppressed by the use of a .rhosts file in your home directory), and then provided with a login session on RemoteMachine, just as if you had typed
```
prompt% rlogin RemoteMachine
```
Note that the prompt for a password may well be a slightly different text than you are used to from rlogin.
Instead of using rsh to run a single command on a remote machine, you can use ssh:
```
prompt% ssh RemoteMachine some-command
```
Whereas rsh will only work if you use the .rhosts mechanism to suppress password prompting, ssh is quite happy to prompt you for a password should it need to, before executing some-command .
Instead of using rcp to copy a file from one machine to another, you can use scp:
```
prompt% scp RemoteMachine:/some/file/name localfile
```
The syntax is identical to rcp, but as with ssh this version is quite prepared to prompt you for a password should it need to. Also, with the most recent releases of the ssh package, the scp client in its default configuration will print a regularly updated status report indicating how much data it has copied, what percentage of the total that makes, and how much longer it expects to take.

Using ssh on the CUED teaching system

At the moment, ssh, slogin, and scp are not available in the standard search path on the teaching system. They are located in the directory /opt/ssh/bin and you will need to either modify your initialisation scripts, or explicitly call the programs as (eg) /opt/ssh/bin/slogin.

Why use ssh?

This section includes both an attempt to motivate those who doubt the point of secure communications, and a brief list of situations that merit the use of ssh for those who want to use it

Why use ssh: For the doubters

Many people may wonder why they should use ssh. An often heard statement is that "I have no data or files that I would mind anyone else looking at, so why should I worry about security?".

There are several problems with this:

Good neighbours.
You may not mind random hackers coming along and using your account to look at your files. The next site that they attack, using your account as an intermediary (thus covering their trail a bit more) may not regard it as such a trivial matter.
Data integrity.
While instances of malicious corruption of data have so far been rarely reported, and have tended to be of the "disgruntled employee" type, the risk of an intruder changing the contents of files that may contain data vital to your research should not be underestimated.
Traffic analysis.
If you only ever use secure communications for the small amounts of material that are "sensitive", you give a potential attacker large amounts of information about what is worth trying to attack.

Finally, although this doesn't necessarily imply that you have to use ssh all the time, you should be aware that taking whatever appropriate steps are necessary to keep your computer accounts and facilities secured from unauthorised use is a requirement specified in the university rules for use of I.T facilities, breach of which is implicitly illegal under the Computer Misuse Act

Why use ssh: For those keen to use it

When connecting over untrustworthy networks.
- Suppose you wish to connect to a CUED machine from your computer in college. You trust your own computer, and the machine in CUED (of course ...), but you're not too sure about other people on your staircase who are on a shared ethernet segment with you. Using the ssh utilities, you can be sure that they have no way of observing your CUED password that you need to type, or any of the data that may pass between the machines.
- Alternatively you may be attending a conference. You have your portable computer with ssh clients installed, and your hosts are prepared to allow you to plug it into their local ethernet. Using ssh, you can be assured that your passwords won't be snooped by malicious users on their ethernet. At least four major intrusions of sites within the University of Cambridge in the last few years have been the direct result of local users connecting back to their "home" machine from a site which had compromised ("hacked") machines that were observing all data on that network.
To get X11 to work nicely
There is more detailed documentation about how to do this in the advanced use section . However, very briefly, ssh and slogin will, when the DISPLAY variable is set, transparently arrange for X11 clients run in the remote session to be displayed locally, with DISPLAY variables and X11 authentication completely automatically set up, and with all transferred data (eg X keystroke events) encrypted.
When transferring sensitive data
Even if you're fairly sure your local network is not being snooped, it is probably worthwhile using ssh programs for administrative tasks that require priveleged access to remote machines, or where you are transferring confidential data between machines (whether explicitly by doing a file transfer, or by viewing the contents of a confidential file on one machine while remote logged in from another).
All the time
Security experts would probably encourage you to use ssh programs all the time, rather than only when you're doing something sensitive. The argument behind this is that you tell a potential attacker an awful lot if you only use secure communications occasionally - they can be fairly certain that the comparatively small volume of data that is secured is worth attempting to decrypt. On a more straightforward note, if you always use these programs, you don't risk accidentally forgetting to use them on an occasion when you ought to.
In any event, while ssh does use rather more processor resources than the insecure alternatives, the difference is not an unreasonable burden on a reasonable modern computer.

Reasons not to use ssh?

One of the main dangers of packages such as ssh is that they can lead to a false sense of security if mis-used. Unless you have an accurate model of what the software is doing for you, you can believe that you are being secured when you are not.

An example

I am sitting at MachineA using it. When I type at its keyboard, my keystrokes are only potentially visible to processes running on MachineA. If I believe MachineA to be non-compromised, I am happy and don't have to worry about attackers who may very likely be observing the network.

Now I log into MachineB using rlogin. Everything I type during my session on MachineB is visible to anyone who can observe the network between MachineA and MachineB.

Next I transfer a file from MachineB to MachineC using scp. The data in the file transfer is encrypted, and thus not observable by someone who can snoop the network between MachineB and MachineC. The only information that the attacker snooping the network between MachineA and MachineB can glean is what I typed during this session in order to run scp. Thus they won't see the contents of the file transfer (which was made directly from MachineB to MachineC), but they will see the password or passphrase that I will (in many cases) have had to type to get scp to work, because that was typed on MachineA and sent in clear to MachineB (via the rlogin) before being encrypted by scp to be sent to MachineC.

Finally I slogin from MachineB to MachineC. Again, while observers of the network between MachineB and MachineC will not be able to observe any password I used to do this, or any data I type in to or read from files on MachineC, observers of the network between MachineA and MachineB can see every detail.

Had I originally used slogin to connect from MachineA to MachineB, subsequent activities involving slogin or scp between MachineB and MachineC would have been completely secure.

However, all of the above assumes that no-one has compromised the machine you are actually typing at. Again, be careful that the fact that you are using a whizzy piece of cryptographic security program doesn't lull you into a false sense of security about aspects of your computing environment that ssh has no control over ...

How ssh works

on a separate page

Using ssh (more advanced)

on a separate page

Installing and administering ssh

on a separate page

SSH versions and Licensing

There are two major versions of the SSH protocol (the standard that defines how ssh servers and clients should talk to each other).

SSH Version 1 (protocol version 1.5)

This is the version of the protocol used by the ssh software installed within CUED . The license agreement provided with this implementation of ssh for unix systems permits the use without payment of the software within educational institutions.

At the time of writing, there does not appear to be a useful, free implementation of ssh using version 1.5 of the protocol for any platform other than unix, with the exception of client side support in PuTTY

Unfortunately, there are fundamental, though subtle, flaws in this protocol that result in vulnerabilities should an attacker be able to both observe and insert data being sent between ssh client and server (although work-arounds to this problem are installed in the latest releases of this version installed locally).

SSH Version 2 (protocol version 2.0)

This version of the protocol is being proposed as an Internet Standard (although its acceptance apparently depends on at least two independent implementations being available, which there aren't yet). Unfortunately, the license agreement provided with the only available implementation of ssh-2 for unix systems is sufficiently restrictive that we cannot usefully make it available on computer systems within CUED .

It is therefore the case that support for SSH Version 2 will not be available within CUED until a non-restrictively licensed version has been written.

Currently, the most promising development is the OpenSSH project . This is the OpenBSD project reimplementation of the ssh tools, which, although it doesn't yet support 2.0, is working towards it.

Update (31aug2000): OpenSSH v2.1.1 supports both protocol versions, and installation on the teaching system is being pursued. Also, it looks possible that the licensing on the commercial SSH Version 2.3 has derestricted use in academic institutions sufficiently that it may be possible to recommend its use. More news on both these issues as soon as possible.

Update (25jul2002): OpenSSH is now at v3.4

Available client software / supported platforms

Unix

On unix platforms, both version 1 and 2 implementations are available, but beware of the licensing restrictions on version 2 . The latest releases at the time of writing were ssh-1.2.27 and ssh-2.0.13.

There is information about installing and administering the ssh package on unix platforms available in these help pages.

Windows

PuTTY is a free telnet implementation that includes SSH support.
A commercial implementation of ssh clients for Windows (3.1, 95, NT) is available from DataFellows.
Other pointers to relevant material may be found at http://www.sorted.org/~chris/ssh/ .

Macintosh

MacOS X comes with native openssh. So slogin &c are available on the command line.
A commercial implementation of ssh clients for the Macintosh is available from DataFellows.
Update (25jul2002) A free implementation of ssh-2 called MacSSH is available, but does not support the ssh-1 protocol.
Update (25jul2002) A free implementation of ssh-1 called NiftyTelnet is available, but does not support the ssh-2 protocol.

[Help]

Updated on 8th Jun, 2001
Patrick Gosling

jpmg@eng.cam.ac.uk