Setting Up SSH

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:

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:

	Dear Fawn,
	I have some important documents that
	must leave the office secretly.  Could
	you stuff them into your boots?

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


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 ( 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.


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 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:

	bill@peter $ ssh
	bill@paul's password: [type your password here]
	Welcome to
	bill@paul $ echo ' bill' >> ~/.shosts
	bill@paul $ chmod 600 ~/.shosts
	bill@paul $ ssh
	bill@peter's password: [type your password here]
	Welcome to
	bill@peter $ ssh paul
	Welcome to

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.


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.

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:

	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.
	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
	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.
	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 *
	  Cipher blowfish
	Host *
	  Compression yes
	  Cipher blowfish

Some other interesting options for your config file would be:


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:

(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.

	bill@peter $ ssh paul
	Welcome to paul.
	bill@paul $ echo $DISPLAY
	bill@paul $ xlsclients
	peter  /usr/bin/X11/xterm 
	bill@paul $

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 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

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


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/

The contents of (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.

	bill@peter $ ssh paul
	Enter pass-phrase for RSA key 'bill@peter': [Type your pass-phrase here]
	Welcome to paul

	bill@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`
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.


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: => SOMEHOST.MIT.EDU [23]
	ssh someotherhost -l bill
	cd Mail

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

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.

Original by Wolfgang Wander

Last modified: 2002-01-30