>I've received the following warning, asking me to contact you.
>How should I proceed. 
>
>
>derwent% ssh shell1
>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @


When you ssh to shell1, how do you know that it is shell1?  How do you know
that an attacker hasn't set up a machine pretending to be shell1, which
will let him snoop on you as you log in?

The way this is checked is with a 'host key' which is stored only on
shell1.  Whenever you ssh to shell1, the ssh program asks shell1 to prove
that it has this key.  If shell1 cannot prove that it has the recognized
host key, or tries to use a different key, then ssh gets suspicious and
thinks it might be another machine masquerading as shell1.

There are two reasons why this might happen:

- It really is a machine set up by an attacker to look like shell1 and get
access to all your private information; or

- shell1 has been reinstalled and a new host key has been generated.

In this case it is the latter, but it is certainly the Right Thing for
you to check first.

(However, the general security of our systems is not
bulletproof - for example, any files in your Unix home directory would
be easy to access using a laptop or even a lab machine booted from
floppy - so it's unnecessary to be too paranoid about ssh and its host
keys.  If somebody wanted to crack your account, there are probably
easier ways to do it than man-in-the-middle attacks on ssh.)

How to proceed?  Now you know that the change in host key is genuine,
and not the result of some intruder, you can tell ssh to forget about
the old key and use the new key next time you connect.  Ssh's collection
of keys to check is stored in the file ~/.ssh/known_hosts, as mentioned
in the message.  You need to look at that file and remove the line for
'shell1.doc.ic.ac.uk'.  Then you should be able to ssh to shell1, and you may
get a message about the host key being unrecognized, and do you want to
add it into the known_hosts file.  Say yes.

As I mentioned above, it's probably not worth checking by hand every
time a host key changes, although morally you should.  Because the host
key changes on every reinstall and the lab machines are reinstalled
quite frequently, if you're sshing to a lab machine you'll find the 
keys is likely to have changed - so you have to remove the old line from
~/ssh/known_hosts.