why ssh: why do we need encryption. 
where: where to get ssh. 
telnet/rsh/rlogin: how ssh replaces these tools. 
ftp: using ftp with ssh or scp instead of ftp. 
fine tuning: getting the best performance out of ssh. 
X11: tunnelling X11 traffic through the secure link. 
keys: keys and key-servers. 
drawbacks: when using ssh is not secure. 
In an emergency:

If you must use a computer without ssh, and you do not have authority to install software on it, then you have these choices: 
Use this Java applet inside Netscape or another Web browser with Java enabled (which is not recommended in general!) and up to date. 
If the applet does not work properly, and you must use the public Internet to connect, then use telnet to connect to athena.dialup.mit.edu and login to your Athena account, followed by ssh to your computer at LNS. The campus network at MIT almost certainly has unauthorized "sniffers," and it is "dirtier" than most public networks. 
Why SSH?
Why do we need encryption?

Almost all computers at LNS are connected to the Internet, all the time. Besides providing ways for us to communicate and collaborate with others all over the world, the Internet also provides a path for intruders from all over the world to try to gain access to our computers for their own purposes. 

Typically an intruder will try to gain access either by exploiting a software bug in order to login without a password, or by gaining access to another related computer and running a "sniffer" program to spy on passwords as they travel over the net. The Computer Services staff try to "patch" over software bugs as soon as they become known, and to detect and stop sniffers before they gather any passwords. But it is everyone's job to keep their passwords secret, and to avoid sending them over the net in plain view of sniffers. Instead, you should use encryption to hide them. 

No matter how they gain access, a successful intruder can cause a lot of damage, by removing important files or by flooding the net with messages in an attempt to disrupt rivals. In the last years, other research labs have suffered large amounts of damage from intruders. At LNS, we see probes from would-be intruders every day. We have to assume that they will try to invade us if we are not careful. 

Even if you think that your computer account is not very important to you, it can still provide an opportunity for intruders to break in and hurt other users. So we should all try to be "good neighbors." 

Many computers at MIT use Kerberos for encryption. For example, if you read your e-mail on Athena, or if you use MIT administrative systems through the net, then you do not transmit any clear text passwords over the net. However none of the LNS computers do Kerberos encryption and thus you should never use telnet to connect to another machine at LNS or outside LNS. Instead please restrict yourself to ssh. 

Some unfriendly person might be interested in your network traffic and start logging all your sessions. Such a session log might look like: 
    9600,9600.#.host.mit.edu:0.0.DISPLAY.host.mit.edu:0.0
    USER.north.....XTERM........Secret
    mail  
    Dear Fawn,
    
    I have some important documents that
    must leave the office secretly.  Could
    you stuff them into your boots?
    
           Ollie
    .

Most unfriendly persons (unless they are special investigators) are not particularly interested in your e-mail conversation but will find your username and password much more noteworthy. Why? Because this means that they get access to another host on which they might obtain root access and install a sniffer which can log all the sessions on your local network as well. 

Most crackers nowadays use this strategy to break into a single host, then set up a sniffer to obtain usernames and passwords for other hosts, so that they can spread over various institutes within a few days. It's the responsibility of every user to avoid unencrypted traffic -- such as from telnet, rsh, rcp, rlogin, ftp, pop3, imap -- to avoid these kinds of network intrusions. 

Here is an example of a sniffed ftp session - username and password are modified. 
    USER ken
    PASS Investig
    CWD logs
    PORT 154,201,54,21,44,5
    NLST telnet.logs
    PORT 154,201,54,21,44,6
    RETR telnet.logs
    QUIT
Where?
Where to get ssh.

Unix users can get the ssh source code from the SSH home page or the Open SSH page. Most likely you won't have to compile the source code yourself: At LNS your Linux workstation will have ssh installed automatically. All Computer Services servers have ssh installed. 

We recommend that Windows users download SecureCRT from the MIT SecureCRT Webpage. SecureCRT has superior VT emulation, and it is available free to MIT users because MIT has a site license. Information about the license and how to install it can be found in the readme file on the MIT Webpage. If you can't download SecureCRT, for instance if you are at home and you are using some ISP other than the MIT Tether service, purchase SecureCRT from Van Dyke Technologies, Inc. Or try the freeware ssh client: SSH Sources+Binaries by Robert O'Callahan ( .edu) as an extension to the free+excellent telnet program Teraterm Pro. 

For Macintosh users, we recommend NiftyTelnet (for ssh1) or MacSSH (for ssh2). Another choice is to buy an SSH client from F-Secure. The product is reasonably priced and works reliably. Some of the vt100 features are not correctly implemented, however. 
telnet/rsh/rlogin
How ssh replaces these tools.

SSH works very much like telnet or rsh/rlogin. You connect to another host typing 
    ssh hostname.domain

or if you use another username on the remote host you use the -l option to specify this username: 
    ssh hostname.domain -l otherusername

The first time you connect to this host, ssh recognizes that it has never learnt the public key of this host so far, and it warns you that it does not yet know this host: 
    Host key not found from the list of known hosts.
    Are you sure you want to continue connecting (yes/no)? 

Most people answer this question either with 'no', 'n' or 'y'. In all these cases the connection will be aborted. SSH expects you to answer this question with 'yes' (a three letter word). 

If you are really careful you could ask the system administrator of the remote host to send you the host public key in a PGP-signed message. You could then add this key to your file ~/ssh/known_hosts. You don't have to be THAT careful ... normally. 

If you are used to the password-less rlogin, ssh offers a similar mechanism. You should edit the file ~/.shosts and add the line 
    remotehost remoteuser
to it - pretty much the same way as you would do it in the case of the ~/.rhosts file. (Before you do so, please read the paragraph below about keys and key-servers. You might not need ~/.shosts at all.) 

However you should know that ssh is a little more picky about these kinds of logins. It checks carefully that, if you connect from localhost, that this really is localhost and not happy.cracker.org using a spoofed connection. The ~/.ssh/known_hosts file on the remote host therefore has to contain the public host key of localhost. The easiest way to do that is to connect (still with typing your passwords) from your localhost to remotehost and back again - always using the so called fully qualified hostname, i.e. the host name including the domain name: 
      $ ssh paul.mit.edu
      password: [type your password here]
    Welcome to paul.mit.edu
    
      $ echo 'peter.mit.edu bill' >> ~/.shosts
      $ chmod 600 ~/.shosts
      $ ssh peter.mit.edu
      password: [type your password here]
    Welcome to peter.mit.edu
    
      $ ssh paul
    Welcome to paul.mit.edu

The second connection from peter to paul was indeed possible without typing the password. Please also note that ~/.shosts should not be writable by any other user (chmod 600 ...). 

In case there is anything not working, you should try to use the -v option while connecting. SSH will then explain in detail why a password-less connection fails. 

Rsh also has the option to execute remote commands. So has SSH. If you've setup your ~/.shosts file as described above you can simply type 
    ssh remotehost remotecommand

the same way you would do it with rsh. The only difference is that in case you have not setup your ~/.shosts file, ssh will even prompt you for your password in the case of a remote command execution. This is better than what rsh can do. 
FTP

In general ssh does not support ftp. You can however use ssh's port-forwarding to enable ftp connections to remote hosts. This method involves a little more effort than the usual ftp connection and you might want to consider to avoid ftp and use scp (see below) instead. 

You will first have to establish a port forwarding ssh connection to the host you want to connect to via ftp. This requires of course that this host runs sshd and you have an account on it. For anonymous ftp connections this is usually not the case but anynomous ftp connections to remote hosts usually don't impose a security risk. You establish the portforwarding connection using 
    peter $ ssh paul -L 1234:paul:21
    Welcome to paul.
       
    paul $ # I am just waiting here and keeping the port forwarding connection up

Here 1234 is an arbitrary local port to which you later connect and 21 is the ftp port number of remotehost. Then you can start an ftp session in another window: 
    peter $ ftp localhost 1234
    Connected to localhost.
    220 paul FTP server (Some UNIX Version x.y) ready.
    Name (localhost:bill): bill
    331 Password required for bill.
    Password: [type bill's password on paul here]
    230 User bill logged in.
    Remote system type is UNIX.
    Using binary mode to transfer files.
    ftp> passive
    Passive mode on.
    ftp> 

Don't get confused by all these different hostnames. The user bill on peter connects to the ftp server on localhost's (this is peter's) port 1234. Due to the port forwarding (-L 1234:paul:21) above this port is forwarded via the encrypted ssh channel to paul's port 21 - the ftp control port. This is why the local ftp client answeres Connected to localhost whereas the remote ftp server says 220 paul FTP server (Some UNIX Version x.y) ready. You will then be prompted for a username and password. These should correspond to your account on paul, the remote host. Before doing anything else you will have to enable passive mode in the ftp client using the passive command. This will make sure that the connections from the ftp-data port (20) will reach your ftp client. 
Using scp instead of ftp.

Copying files with ssh is done using the program SCP. It works similar to rcp: 
    scp localfile remotehost:/remotedir
    scp localfile remotehost:
    scp -r localdir remotehost:/remotedir
    scp remotehost:remotefile localfile
    ...

If you have setup your ~/.shosts file you will not be asked for a password during these operations. More details can be found in the man page for scp. 
Fine tuning
Getting the best performance out of ssh.

Encryption does require CPU time to encrypt and decrypt the data. Therefore ssh connections and scp file-transfers are usually a little slower than unencrypted connections. SSH offers different kinds of encryption, so called Ciphers which have different levels of security and CPU requirements. The ssh README.CIPHERS file compares these different options: 
    BLOWFISH
    ========
    
    Bruce Schneier's block cipher that was designed to be a fast and free
    alternative to existing encryption algorithms. It is unpatented and
    license-free. SSH version uses a 128-bit key for Blowfish (the
    algorithm allows anything from 32 to 448 bits).
    
    Performance on a pentium machine is about 88% of "none" encryption.
    
    You can disable it by giving the --without-blowfish option to
    configure. It is ON by default.
    
    [...]
    
    IDEA
    ====
    
    A 128-bit block cipher. Faster than 3DES, but slower than Arcfour and
    Blowfish. The IDEA algorithm is patented in many countries, and the
    patent holder disallows commercial use (their definition of
    commercial use include connections from one corporation to another
    corporation).
    
    Performance on a pentium machine is about 64% of "none" encryption.
    
    You can disable IDEA by giving the --without-idea option to configure. 
    It is ON by default.
    
    [...]
    
    3DES
    ====
    
    Three-key triple-DES (effective key length of about 112 bits) in inner
    CBC-mode. This is the default fall back cipher that is used if the
    client asks for a cipher that isn't supported by the server.
    
    RSA private key files are encrypted by 3DES by default. (Some older
    versions encrypted private key files with IDEA, and such key files may
    still be around.)
    
    Performance on a pentium machine is about 45% of "none" encryption.
    
    You cannot disable it, because it is the mandatory cipher.
    [...]

SSH and SCP accept commandline options to specify the cipher preferred in the connection. The default cipher is IDEA and therefore you might consider to use 'blowfish' as your default as it is much faster. SSH has a user configuration file in ~/.ssh/config. The format of this file is described in the ssh man page. 

To enable 'blowfish' for all your connections your ~/.ssh/config file would read like this: 
    Host *
      Cipher blowfish

SSH also allows to compress the network traffic. This is a very interesting option if you either use ssh over a modem line or to a (very) remote host. However compressing takes again a few more CPU cycles so you should balance the network speed against your cpu speed. You might change your ~/.ssh/config to 
    Host *.mit.edu
      Cipher blowfish
    
    Host *
      Compression yes
      Cipher blowfish

Some other interesting options for your config file would be: 
ForwardAgent yes
to pass authorization information over the encrypted link (see below). 
ForwardX11 yes
to forward X11 traffic over the encrypted link (see below). 
RhostsRSAAuthentication yes
To enable the use of ~/.shosts files. 
RSAAuthentication yes To enable the use of authorizing rsa key pairs (see below). 
FallBackToRsh no To disable an accidental use of rsh if the user requested a ssh connection. Ssh falls back to rsh by default if the remote host does not understand the ssh protocol. 
X11
Tunneling X11 data through the secure link.

Starting a graphic session on a remote host usually involves setting the DISPLAY environment variable on the remote host to myhost:0.0 and allowing the remote host in some way to access the display on myhost. 

(1) This can be done using the command (strongly deprecated) 
    xhost + 

which unfortunately still many people do. This command enables access for every computer on the Internet. Access means, for example: 
Anyone can download your screen content and see what you are doing. 
Anyone can get every single keystroke you do and filter out sequences like telnet remotehost and the next two lines. 

(2) A little better but by far not optimal is to select a specific host to which one grants access using 
    xhost +remotehost

This still means one has to trust every (potential) user on remotehost that (s)he will not start keyboard sniffers or download your screen image. 

The MIT magic cookie is a much better solution - however difficult to use for most users. You find information on this method in the man page to xauth. 
    xauth extract - $DISPLAY | 
        ssh remotehost xauth merge -

It grants permission based on a cryptographic cookie - the X11 traffic itself is still unencrypted and can be sniffed by an unfriendly person. 

(3) The final solution to these problem however is ssh. If you enable X11 forwarding and you ssh to a remote host, ssh will set the DISPLAY environment variable to something like DISPLAY=remotehost:11.0. All X11 applications which you start on remotehost will connect to the X11 port remotehost:11.0. SSH will then forward all X11 traffic to your local display using the encrypted link between the hosts. 
      $ ssh paul
    Welcome to paul.
    
      $ echo $DISPLAY
    paul:12.0
      $ xlsclients
    peter  /usr/bin/X11/xterm 
      $

The only possible form of attack would be that someone with access to your remote account could gain access to your display using the encrypted link. This is however a much smaller threat than in the xhost/xauth case. 
Keys
Keys and key-servers or how to type better passwords less frequently.

ssh not only allows password based authentication but also allows authentication via RSA key pairs. 

The advantage of this authentication technique is 
you can protect your logins with passwords longer than 8 characters. 
you can setup your system in a way that you have to authenticate only once per session and then have password-less access to all systems you have enabled for this service. 

To setup ssh this way you will first have to generate a RSA key pair. 
    ssh-keygen

does this for you. ssh-keygen will prompt you for a password which will protect your key-pair against misuse by others who might be able to steal the private part of the key-pair from your system. You should enter a (long) password there. Leaving it empty is strongly discouraged. 

You will then have two new files in ~/.ssh/ 
identity - your secret private key, 
identity.pub - your public key. 

The contents of identity.pub (it is one LONG line) should be appended (as ONE long line) to the file ~/.ssh/authorized_keys on the remote host. 

If you now connect to such a remote host, ssh will first prompt you for the pass-phrase of your RSA key. If this one is correct you can login without typing your normal password. 
      $ ssh paul
    Enter pass-phrase for RSA key ' ': [Type your pass-phrase here]
    Welcome to paul

      $

So far this does not help us to type the pass phrases less frequently. Another ssh program named ssh-agent helps us to store and forward authentication information to hosts we want to connect to. 

You should start ssh-agent when you login to your workstation, preferably in your ~/.xsession file. Put the two lines: 
    eval `ssh-agent`
    ssh-add 
into it before you start up the window manager, and the line: 
    eval `ssh-agent -k`
at the end. After your normal login you will be then asked for you ssh pass-phrase. Some people complain about this procedure that they have to enter their password twice. But - no - the second time is NOT your password but your much-longer-than-8-character pass-phrase. And yes - so far there is no xdm support for pass-phrases. So you have to type a password AND a pass-phrase. 

The good thing about this is that ssh-agent will store your identity and pass it along to every host you connect to. So you'll have to type your long pass-phrase only once per session. 

If you've setup your ssh enviroment this way using RSA key-pairs this also means that your ~/.shosts file is now obsolete. In fact as pass-phrase protected RSA keys provide higher security than the account/host based form of ~/.shosts you should probably deinstall your ~/.shosts files again. Otherwise an attacker who breaks into one of your accounts has automaticly access to all of your machines. 
Drawbacks
When using ssh is not secure.

SSH provides you with all the tools that make your Internet life a lot safer and even gives you some extra comfort with it. The downside is that you are still expected to protect yourself and understand that ssh does not protect you from making mistakes when protecting your data and account information. 
The Mixed Environment

Here is a nice session captured by a cracker on one of MIT's systems that shows the problem is great detail: 
    nyc-ny.ix.netcom.com => SOMEHOST.MIT.EDU [23]
    #'vt100!bill
    Secret
    ssh someotherhost -l bill
    @Secret
    inc
    mailfrom
    cd Mail
    ls
    exit
    exit

hosts, usernames and passwords are modified. The user came in from his Internet Service Provider to the machine somehost via telnet and started a ssh session to his host someotherhost. The intruder captured the insecure telnet session and gets all ssh passwords in clear text. If the first connection had been a ssh connection, there would have been no chance to capture the passwords. 

As long as users use both ssh and unencrypted logins there is no password security. The cracker might capture the password on your only unencrypted connection (this might just be a ftp connect to your system) and then he can happily use ssh, your username and password. 

Please note that it is however ok to use mixed encryption environments: You can login to an athena.dialup server using kerberized telnet (e.g. in HostExplorer) and then run savely 
    add crypto
    ssh someotherhost 
Insecure remote hosts

When you connect to a remote host which is insecure, namely it is likely that crackers or other unfriendly persons have access to root or your account on this machine you should disable 
X11 forwarding to this host (see the description of ~/.ssh/config above). 
Authorization forwarding to this host. 

The unfriendly person might otherwise get access to either your X11 display or to all your hosts which trust your identity stored in the ssh-key-server. 
Too short or No pass-phrase

Should a cracker gain access to your account he usually cannot use the ssh keys stored in your ~/.ssh/identity file unless you specify short, obvious or no pass-phrases with this identities. 

Once a cracker has access to your identity he can connect to all hosts which trust your identity so choosing a good, long pass-phrase for your key is important. 

Questions? Comments? Mail us! 
Credits: Patrick Decowski for many useful corrections and additions.