If you are familiar with using ssh1 and/or ssh2, you will notice
some changes to the CS systems that were put in over the spring break.
ssh1 and ssh2 provide better security by encrypting your connection between
machines, and allows you to authenticate the fact you are connecting to the
machine you think you are connecting too.
First off, ssh1 now replaces all rlogin,rsh and rcp connections made from
the CS department. If you use rlogin, rsh or rcp, you do not need to change
the way you use them; the change should be relatively transparent. At times,
when you connect to a machine outside of the computer science department,
you may see a message such as this:
rlogin foo.bar.org
Secure connection to foo.bar.org refused; reverting to insecure method.
Using rsh. WARNING: Connection will not be encrypted.
What this means is that foo.bar.org does NOT support ssh1 connections, and
ssh1 is reverting to attempting a standard rsh connection. This will not
be encrypted as it would using ssh1 or ssh2.
SSH1:
This can be envoked by running rlogin or rsh from one of the
CS machines, as well as /usr/local/bin/ssh1. This will create a $HOME/.ssh
which will hold information about the hosts you connect to that you trust
their hostkey. When you connect to an unknown host, you will be prompted if
you trust that host is what you are expecting it to be. When you
answer 'yes', the host's public key will be stored in $HOME/.ssh/known_hosts.
From then on, when you connect to that machine, the public key will be compared
to what is stored in $HOME/.ssh/known_host, and if they do not match, a warning
will be displayed. It may be that the other host has updated it's host key,
or the other host may very well be masquerading as the host you want to connect
to. So be careful!
SSH2:
Ssh2 is set up to either use password verification or public/private key in order to connect to
one of our CS machines.
If you wish to use public/private keypairs, you can follow these instructions: Ssh2 creates a directory within your account: $HOME/.ssh2 The
quick way to get set up to use ssh2 to is to run the program /usr/local/bin/ssh-keygen from this directory. A keypair will be generated, and you will be
prompted to enter a pass-phrase. This phrase should be more than a word or
two, and something that you can remember. two files will be created within
the directory. One will be a public key (which can be readable by anyone) the
other will be a private key (which should only be readable by you). You
will then have to edit/create the following files and add the following lines:
$HOME/.ssh2/authorization:
*:
Key [keyname].pub
$HOME/.ssh2/identification:
*:
IdKey [keyname]
This will give you ssh2 access to machines within the department.
When you connect from one CS machine to another, you will be prompted
for your pass-phrase. If you are able to provide it, you will be connected
to the other machine.
For now, rlogin connections using the berkeley rsh and rlogin commands will
still be allowed. At some point in the near future these will be denied,
forcing users to use ssh or telnet to connect to the CS machines.
For Windows and Mac Users:
Students will have to provide their own Windows or Mac SSH client. There are many versions, some are free, others charge. We currently aren't recommending any specific ssh client. Since each client is a bit different, you'll have to read the client's instructions for setting up the connections, especially for ssh2. You will need to FTP your public key to your .ssh or .ssh2 directory, depending on what the client wants.
Here are a few places to check for clients:
Windows:
SecureCRT
OpenSSH
F-Secure
FiSSH
PuTTY
Macs:
NiftyTelnet
For additional info, www.ssh.org is a good reference. If you have any problems/issues, please feel free to contact problems@cs.rit.edu