©2001 Bob Johnson
DRAFT - NOT FOR DISTRIBUTION
THIS DOCUMENT IS A DRAFT POSTED SOLELY FOR PUBLIC COMMENT AND REVIEW. PLEASE DO NOT DISTRIBUTE THIS DOCUMENT ELSEWHERE.
Send comments to bob07@garbonzo.hos.ufl.edu
SSH and Secure Shell are registered trademarks of SSH Communications Security, Inc. Unfortunately, "SSH" is also the name of the protocol that their products implement. This document attempts to recognize the distinction between the trademarked term and the generic term as follows:
The trademark name of the SSH product is upper case emphasized font if that is possible on your display device, i.e. "SSH". The generic name for the protocol and associated software is presented in upper case, but not emphasized, i.e. "the SSH protocol". In addition, an effort is made to distinguish the meaning by context. The names of individual programs are in lower case emphasised font, thus ssh is the name of a particular program.
Unix is a trademark of The Open Group. In the interests of brevity and historical accuracy, in this document "Unix" is used to mean "Unix and its close relatives, including Linux". Again, it would be helpful if the trademark owners were to suggest an appropriate generic term if they do not want their trademarked name to be used in the generic sense.
Windows is a trademark of Microsoft, Inc. FreeBSD is a trademark of The FreeBSD Project (FreeBSD, Inc.).
SSH is a protocol for encrypted communication via the Internet.
This section of the Handbook describes how to use ssh to replace older programs such as rsh, rlogin, telnet, and ftp; and how to use it to tunnel other protocols through encrypted channels.
For decades, the Unix world operated on the assumption that the physical network was secure, so there was no significant risk in the use of unencrypted passwords for network services. The Unix philosophy also assumed that it was working in an essentially friendly environment, so that in many cases you could dispense with passwords altogether.
Those days are long gone, but their legacy still haunts many security-conscious network and system administrators. Some of the most frequently used protocols provide no mechanisms for encrypted passwords, or in some cases, any passwords at all. Telnet and FTP, for example, transmit all passwords as plain text. Rsh does not require passwords at all; it assumes that if you come from a trusted host, you must be trustworthy. These and numerous other problems make telnet, ftp, rsh, rlogin, rcp and similar programs unsuitable for use in a modern, hostile, Internet-connected environment.
Recognizing this, SSH Communications Security, Inc. developed a protocol (and software to implement it) intended to replace all of these services and called it SSH (Secure SHell). The OpenBSD Project developed an open source "work alike" called OpenSSH, which is included in the base distribution of FreeBSD 4.0 and later.
This section of the Handbook will explain how to use OpenSSH for various basic tasks related to the management and use of a Unix-like system. It does not attempt to explain the more advanced uses of the SSH protocol, but should provide enough background to allow you to interpret the appropriate man pages if you find that the default configuration is not suitable for your needs. It also does not attempt to explain in detail how to install any specific implementatin of the SSH protocol. That is a topic adequately covered by existing tutorials, some of which are listed in the references at the end of this chapter. Users of Windows systems should find enough information here to explain how to effectively use their SSH protocol client to communicate with a FreeBSD system, although most Windows clients do not provide all of the capabilities of Unix-derived clients.
This section provides background that is probably only necessary if you are attempting to change the default configuration of your SSH server or client. If you simply want to attempt to use the SSH protocols without changing anything, you can probably skip to Using SSH.
As with many other highly flexible software packages, SSH and its relatives can be very confusing to a beginner. How do I install it? How do I configure it? How do I use it to replace telnet, ftp, rsh, rexec, rcp, or rlogin? The basic documentation doesn't seem to provide much guidance to the beginner.
The key to understanding the SSH protocols is to understand that they provide several different methods of secure authentication. You must recognize which is being described by any particular piece of documentation, as well as which is most appropriate to your situation. These authentication methods are discussed below.
You must also recognize that there are three different authentication problems being solved by SSH: one is user authentication, whichdetermines that the person logging in to the server is the person they claim to be; another is server or host authentication, which assures the user that the server they are connecting to is not an imposter system; and the third is client authentication, which allows the server to determine that the that the connection is coming from an authorized client computer.
To accomplish these three tasks, the SSH protocols use a variety of techniques, and you, as a system administrator and/or user, have a lot of control over which techniques get used in any given situation. It is this flexibility that can make SSH so confusing, and it gets worse when you take into account that SSH protocol version 2 has different capabilities and limitations than does SSH protocol version 1. In fact, you should consider SSH1 and SSH2 to be completely independent protocols that happen to be implemented with software using similar names and some of the same capabilities.
Server Authentication: When your SSH client authenticates a server, it does so by receiving a key from the server which it compares to a list of known keys (this is conceptually what happens, although the reality is somewhat more complex). If the key from the server matches the identity claimed by the server, your client is happy. If your client can't find the key or server in its list at all, it will warn you that it cannot confirm the authenticity of the server, and will ask you if you want to connect anyway. You will normally get a warning the first time you connect to a server, since you don't have its key yet. You can avoid this warning by copying the server's key to your system before you connect if you have a secure means of transferring the key (e.g. on a floppy disk).
After the first connection, your client will know the server and will not warn you again unless something changes. If it does detect a change in the server, it will warn you that someone may be eavesdropping on your connection (a "man in the middle attack"). Vulnerability to this sort of eavesdropping is the single greatest weakness in SSH, not because it can't detect it (it can), but because it can't force you to pay attention to the warning it gives you. Programs to perform this eavesdropping are publicly available, so take this warning seriously. Unless you are sure there is a good reason for your client to detect a change in the server (e.g. the server crashed and was rebuilt), you should disconnect until you can determine what is going on.
Client Authentication: The most basic method of client system authentication is traditional Unix rhosts authentication (i.e. the /etc/hosts.equiv or ~/.rhosts files). This method is not secure and should be used with great care, if at all.
In public key host authentication (SSH2) or RSA host authentication (SSH2), your system gives a key to the server, which compares it to a table of known systems just as described above for server authentication. If your system is known to the server, it allows the connection, otherwise it denies the connection. To use this method of client authentication, you must edit the key file on the server and enter the key for each client that is to be allowed to connect.
You can disable this check completely and allow connections from any client system. This makes sense, for instance, if you need to be able to connect to your system from wherever you happen to be when you are travelling. By default, FreeBSD allows connections from any client system. To disable the default and allow only known hosts, add the XXXXXX statement to /etc/ssh/sshd_config.
XXXX: am I misunderstanding something here? How do you prohibit logins from unknown hosts?
User Authentication: The SSH server also needs to confirm your personal identity, so it can determine whether you are authorized to use the services offered. Again, there is a lot of flexibility built in to SSH.
The first method is to simply use traditional Unix rhosts authentication (i.e. the /etc/hosts.equiv or ~/.rhosts files) to authenticate both client systems and users; that is, it assumes that if you come from a trusted system, you must be who you say you are. This is horribly insecure, and is not allowed even as an option by SSH version 2. You would be wise to avoid it as your sole authentication method. You can safely use this method in conjunction with public key authentication, and in fact, this combination is the default configuration for FreeBSD (XXXX is this true?).
SSH can perform public key exchange similar to that used to authenticate the client and server systems, (this is known in version 1 as RSA authentication, and in version 2 as public key authentication). The server keeps a list of known users and their keys, and if you are not on the list, or if your system provides the wrong key, you don't get in. This requires that you add your key to the server's key file before you need to connect with the server. It also requires that you first create your user key by running the ssh-keygen program.
You also have the option of configuring the SSH server to ignore these public key techniques, and simply ask the user to enter their password, just as if you were connecting with telnet or ftp. The important difference is that by this time, SSH has already set up an encrypted connection, so your password will be transmitted in an encrypted data stream, instead of as plain text as with the older protocols. This method has a few advantages, not the least of which is that it is the behavior many users expect from their experience with telnet or ftp. The choice of whether to use cryptographic key authentication or encrypted password authentication depends on personal preference and an analysis of the specific security requirements of your situation. Those issues are discussed in more detail below. Although many tutorials on SSH instruct you to run ssh-keygen in order to use SSH, you don't actually need to if you are using password authentication without RSA authentication.
If you are using password authentication, you can optionally configure OpenSSH to use s/key one-time passwords. If you elect to use this option, you will need to use otp-md5 to generate the one-time password rather than using key, which you may be used to. See opiekey(1) for more information.
If you are using FreeBSD 4.0 or newer, OpenSSH is installed as part of the core system, so all you need to do is make sure you have the crypto distribution included in your installation, and that the line sshd_enable=YES appears in /etc/rc.conf. If you are using an older release of FreeBSD, you can install either SSH or OpenSSH from the ports system.
If you use the original SSH software, an SSH1 client cannot talk to an SSH2 server, nor can an SSH2 client connect to an SSH1 daemon. To support both protocols, you must install both SSH1 and SSH2 on the same server. The SSH2 daemon can be configured to automatically start the SSH1 daemon if it detects an SSH1 client trying to connect, and by default the SSH2 client will start the SSH1 client if you attempt to connect to an SSH1 server. Recent versions of OpenSSH do not have this problem: the daemons and clients speak both the SSH1 and SSH2 protocols, so you only need to have one version of OpenSSH installed. Most FreeBSD users will be using OpenSSH, so this will not be a problem.
You may wish to edit the configuration files (/etc/ssh/sshd_config and /etc/ssh/ssh_config in recent FreeBSD systems, but found in /usr/local/etc on older FreeBSD systems) to adjust the behavior of the server and client to suit your needs. Some information about basic configuration options is below (see Some Configuration Options), but you should read the ssh and sshd man pages before editing the files.
Once you have the server and client config files set up the way you want them, you will need to restart sshd so it will read the new configuration. killall -HUP sshd should accomplish this.
If you are a user planning to use RSA or Public Key authentication, you will need to create a public-private key pair. First, run ssh-keygen, which will create a key pair and install them (by default) in ~/.ssh/identity and ~/.ssh/identity.pub. ssh-keygen will ask you to enter a passphrase, which you will be required to enter every time you want to connect to a remote system. You can leave the passphrase blank, but do so only if you are certain no one else will have physical access to your computer, because without it, anyone who gets a copy of your keyfile will be able to assume your identity. Unless you are absolutely sure that no attacker will successfully break in to your computer (and that no root user on your system will steal your key file), it is wise to protect your private key with a passphrase. The passphrase is used to encrypt your key, so that even if someone steals the key, they need your passphrase to use it. Having to enter your passphrase every time you open a connection is as much of a nuisance as entering your remote password, so there is tool called ssh-agent that asks for your passphrase once, stores it in memory, and provides it to ssh whenever it is needed, until you log off. If your login script runs ssh-agent, it will prompt you for your SSH passphrase when you log in, and you won't have to worry about it after that.
After you have created the key pair, you need to copy the public key to each host you plan to connect to with ssh. You can use ssh to move this file for you:
For ssh1:
scp ~/.ssh/identity.pub alice@remote.example.com/~/.ssh/tempkey.pub
For ssh2:
scp ~/.ssh2/id_dsa_1024_a.pub alice@remote.example.com/~.ssh/tempkey.pub
will use password authentication to move the user's public key file to alice's .ssh directory on the remote system (this assumes that password authentication is permitted by the remote server). She must then edit her authorized.keys file and add the key contained in tempkey.pub. Each key in authorized.keys must be on a separate line.
By default, OpenSSH on FreeBSD is configured to allow both public key and password authentication. This means that unless you run ssh-keygen once to create a personal key, you will be prompted for your password every time you create an SSH connection. You should enter the password for your account on the remote system to which your are connecting.
If you have created a public key pair with ssh-keygen, you will instead be prompted for your local passphrase that protects your personal SSH key. Enter the passphrase that you used when you ran ssh-keygen.
If you run ssh-agent after you log in, it will ask you for your passphrase and provide it to SSH as needed, so you will not need to enter your passphrase again until you log off.
Using SSH as a secure replacement for telnet is simple. The command "ssh hostname" sets up a secure terminal session to the specified host. Various options allow you to handle various situations you may encounter: for example, "ssh username@host.example.net" sets up a secure terminal session using the user ID username instead of your current user ID (ssh -l username host.example.net also accomplishes this). See the ssh(1) man page for more options.
There are two tools available to replace FTP with SSH. One replacement is a tool called sftp distributed as part of SSH version 2 and recent versions of OpenSSH. Sftp is very similar to ftp and should be interchangeable with it. The primary disadvantages of sftp are that it is not available in all implementations of the SSH protocol, and that it is needlessly complicated if you only need to copy a few files with known path names. For many purposes, scp is a simpler, and more widely available, solution. Scp is described below under Replacing rcp. There are also substitutes for sftp that have graphical user interfaces and are easier for many users to master.
By default, sftp support is disabled in the FreeBSD server configuration. If you want to allow sftp connections to your server, uncomment the following line in your sshd_config file:
Subsystem sftp /usr/libexec/sftp-server
Most implementation of the SSH protocol include a secure replacement for rcp called scp. The command
scp bob@mercury.example.com:/etc/printcap printcap
will set up an encrypted connection (requesting a password if necessary) to the user account bob on the host mercury.example.com, and then copy the /etc/printcap file from mercury to the current directory on the client system. This provides a secure file copy method that is more convenient than ftp or sftp for many purposes.
If you are accustomed to using rlogin with rhosts authentication, you will want to configure SSH to provide similar functionality (i.e. no need to enter your password each time you connect), but with the added security of cryptographic key authentication. This is the default configuration for many installations of SSH protocol implementations, although you will need to generate a personal key using ssh-keygen before you will be able to log in without a password. Use is essentially the same as described under Replacing Telnet, above. Some implementations of the SSH protocol include an alias that allows you to invoke ssh with the command slogin.
Ssh is a direct replacement for rsh. The command
ssh puppy.example.org frogman
creates an encrypted connection to the remote host puppy.example.org and then runs the command frogman on the remote host. You can also specify the user account to login in with on the remote system:
ssh alex@puppy.example.org frogman
will run the command frogman as the user alex, assuming you are authorized to log in as alex on the remote system.
Using ssh to replace rexec is essentially the same as described under Replacing rsh, above. The primary difference is in whether ssh is configured to require passwords as part of the user authentication process, since rexec traditionally does not require password authentication.
X forwarding should occur automatically in a properly configured SSH connection. Simply start the X application on the remote system, and SSH will automatically set up an encrypted link to forward the session to your X server (i.e., your client workstation). This requires that SSH be able to run xauth on the remote system, and that X forwarding be enabled in the sshd configuration file on the remote system.
A typical command line to start a remote X session via SSH is
ssh -C -X -f fred.example.com cvsup /usr/local/etc/ports-supfile
The -C option compresses the transmitted data. This will speed things up if relatively fast computers are talking through a relatively slow connection. The only way to know what "relatively" really means is to try it with and without the -C option and see which is the fastest. You can control the degree of compression (and thus the speed tradeoff) in the client configuration file, ssh_config.
The -X option requests that X forwarding be enabled. Depending on the version of SSH you are using, and the details of your configuration files, this option may not be needed. SSH2 by default disables X forwarding unless specifically requested with the -X option.
The -f option tells SSH to set up the connection and then go to the background. This is necessary if you will need to enter your password to set up the connection, but want your local command prompt back after the connection is established. If you will not need to enter a password, you can use the -n option instead, which goes to background mode before setting up the connection. If you use neither option, your local command prompt will not return until you close the X session.
You may find that some applications require you to install the fonts they need on your local system.
You may also find that some applications will not start properly unless you start a remote xterm using a command such as
ssh -C -X -f fred.example.com xterm
and then start the application as you normally would from that xterm window. The new application will use the same X display as the xterm session, and will thus open a new window on your local system. This may, for example, be the safest way to run a remote X application that must be started by the root user: i.e., start the xterm, su to root in the xterm, then start the application. By doing it this way you avoid having to allow remote logins from a root user.
Many services can be forwarded via SSH: the only requirements are that they be listening for connections on a known port number, and do not open other ports as part of their operation. For example, to forward a POP3 connection, use something like:
ssh -L 1110:fred.example.com:110 fred.example.com
Then set your email program to connect to localhost:1110 (i.e. port 1110 on your local system). The connection will be encrypted and forwarded to the POP3 port (port 110) on fred.example.com. The command line effectively says "tunnel (or link, if you'd like a mnemonic) port 1110 on the local system to port 110 on fred.example.com, using the SSH server at fred.example.com as the relay that performs the tunneling."
Note that you can also use a third party SSH server as a relay, e.g.
ssh -L 1110:fred.example.com:110 bobj@joe.example.net
but the connection will only be encrypted between your local system and joe.example.net. The connection from joe.example.net to fred.example.com will not be encrypted. This may still be useful as a means to get traffic out of a local network that you know you cannot trust (e.g. a cyber cafe).
If you want other systems to be able to connect to the forwarded port, use the -g option. E.g.
ssh -g -L 80:www.example.com:80 bobj@www.example.com
will allow other systems to connect to port 80 on the local system to access the web server on www.example.com. Note that you may not be able to easily shut down the forwarded connection if someone else is connected to it.
(This section is not yet complete)
Server Configuration
Important files on the server (in some installations, the global files will be located somewhere other than /etc/ssh):
/etc/ssh/sshd_config The server configuration file.
/etc/ssh/ssh_host_key This file contains the private part of the hosts's public-private key pair. It should be owned by root and accessible only by root.
/etc/ssh/ssh_host_key.pub The public part of the hosts's public-private key pair. It should be world readable, but writable only by root.
~/.ssh/authorized_keys (SSH1.3 & 1.5).
~/.ssh/authorized_keys2 (SSH 2).
A list of keys that are permitted to authenticate the user (i.e. a list of keys from other systems that can be used to log in as this user). By default, the list of authorized keys for a given user is determined by that user, and public keys for that user from other systems must be copied to the authorized_keys file to allow the user to log in from those systems.
/etc/ssh/ssh_known_hosts
~/.ssh/known_hosts
/etc/ssh/ssh_known_hosts2
~/.ssh/known_hosts2
These files contain the host public keys for all known hosts, i.e. it is the lists of hosts that are allowed to connect to the server. By default, connections are authorized from all hosts, and the key for a new system is automatically added to a user's individual list whenever that user connects from a new system. This may seem useless, but it is the mechanism that allows SSH to detect "man in the middle" attacks on your encrypted session.
/etc/nologin If this file exists, sshd will not allow users other than root to log in.
~/.shosts
/etc/hosts.equiv
/etc/ssh/shosts.equiv These files are used to allow passwordless logins. By default, if XXXX...
~/.ssh/environment
~/.ssh/rc
/etc/ssh/sshrc
Useful server configuration options:
X11Forwarding Yes
Enables automatic forwarding of X sessions from the SSH server (the X11 client) to the SSH client (the X11 server). Because a user can easily set up X11 forwarding via other means, there is very little security risk in enabling X11Fordwarding on the server.
By default, FreeBSD 4.0 and later will use DSA key authentication if it is available, and to fall back to password authentication if the user doesn't appear in the server's authorized_keys file. This allows your users to use the authentication method that is most appropriate for them. It also gives new users a mechanism for logging in to your system for the first time, so they can securely transfer their public key to the host using scp(1).
Client Configuration
Important files on the client: (XXXX needs work!)
Enable automatic X forwarding on a client creates a slight security risk. How? I don't remember.
Compression yes
This statement will enable compression by default (otherwise it must be invoked with the -C command line option).
CompressionLevel 6
This controls the level of compression your client requests when compression is enabled. A higher number means more compression, but requires more CPU time to do the compression. Values can be from 1 to 9, with higher numbers working better with higher cpu speed/connection speed ratios, while lower numbers work best if the server has a slow cpu or you have a fast connection. If your connection is fast enough, you may not want to enable compression at all.
SkeyAuthentication yes
This enables the use of s-key one-time-passwords for authentication via SSH. FreeBSD uses the OPIE s-key implementation. When this option is enabled, and the server supports it, the user will be prompted with an OPIE prompt such as otp-md5 309 sc0756 ext. Run the otp-md5 program on a trusted system to generate the correct response (you can generate a printed list of responses in advance and keep it in your wallet), or press <enter> a few times and it will give up on OPIE and try another authentication method. Read about opie(4) for more information.
Private Key Security
Typically, SSH tutorials tell you to use public key user authentication rather than password authentication. This practice is based on assumptions that do not necessarily apply in all networks. You should review your situation and decide what authentication methods best meet your needs.
Public key authentication depends on the existence of a pair of keys; a public key and a private key. Your public key is the key you copy to the server's authorized user file. Your private key should be just that: private. If your local host is an inherently insecure system, such as a Windows 98 system in a student computer lab, you should not expose your private key to theft, and it may be more appropriate to use password authentication. Even if you use a passphrase to protect your private key, you are almost certainly using a passphrase that is much easier to break than is the encrypted connection. Many administrators consider Windows 95/98/ME systems sufficiently insecure that it is never safe to trust private key files on them, so they always configure SSH to require password authentication on their networks as an added barrier to unauthorized users.
Another situation in which private key files are often exposed is when users mount their home directories via NFS. This arrangement often allows another user to either sniff the key file from the network as it is accessed, or actually mount the home directory and copy the private key file.
Password authentication, on the other hand, suffers from many of the same deficiencies as any password-based system: it requires the user to keep the password secure. Because many users are unable to properly protect a password, you may decide that the risk of your users compromising their own passwords is greater than the risk of keyfile theft, and elect to use public key authentication in your network.
In another scenario, an attacker may break in to a system that runs an SSH server, and install a modified sshd. The attacker's modified sshd harvests passwords typed in by users logging in to the system, and the attacker can then test those passwords to see if they work on other systems or accounts the user has access to. If you use public key authentication, the attacker in this situation cannot gain information that is portable to other systems or accounts.
Finally, if you use SSH to connect to your home system from untrusted systems (e.g. student computer labs or public cyber cafes), you must confront the fact that the owner of the system may be capturing every keystroke you type on the keyboard, thus capturing your password or your key passphrase. In such situations the only secure authentication method is a one-time password system, such as skey. FreeBSD with OpenSSH supports the use of skey authentication as an option (XXXX at least FreeBSD 4.2 does).
File Transfer Security
Prior to (roughly) the fall of 2000, SSH version 1 and OpenSSH had an important security problem. With those older versions, if you do an scp transfer from a system that has a hostile SSH server installed, the server can install files anywhere on your client system that you have permission to write files. For this reason, you should never do scp transfers as a privileged user (e.g. root), and you should not use scp to transfer files from an untrusted system unless you are using the SSH 2 package, or have installed an appropriate patch or upgrade for your SSH-compatible software.
Note that the programs SSH replaces, such as rsh, tend to have this problem also, so you are better off using SSH with appropriate care than going back to its predecessors.
Other Issues
(This section still under development)
Keep in mind that using SSH does not eliminate the need for good "password hygiene". You should still use passwords that are hard to guess and that will be resistant to dictionary attacks, and you should change your passwords as often as is practical to reduce the likelyhood that a compromised password will be used at some date in the future. Similarly, you should use different passwords for different services and different host systems, so that if a password is compromised, the attacker will not gain access to multiple services or hosts.
For more discussion of the issues you should consider when selecting public key or password authentication, see XXXX.
An introductory tutorial on installing SSH and getting started using it. Includes details on how to use many of the individual commands in the SSH package:
http://infobase.ID-PRO.de/howto/Security/SSH/Getting_started/
A very good FAQ for SSH :
http://www.employees.org/~satch/ssh/faq/ssh-faq.html
ssh(1) man page, discusses client options, and the client configuration file.
sshd(8) man page, discusses server options, and the server configuration file.
http://www.freessh.org/ has an extensive list of SSH-compatible freeware.
SSH Communications Security, Inc. --
Developers of the SSH protocol. http://www.ssh.com/
F-Secure :
Full-featured commercial SSH implementation for Windows, Mac, & Unix. Unlike many Windows clients, it can do port forwarding. Can be downloaded for trial period. http://www.f-secure.com/
OpenSSH:
An open source, freeware implementation of SSH for Unix derivatives. Included by default with recent releases of OpenBSD, FreeBSD, and others. http://www.openssh.com/
PuTTY:
Good freeware Windows implementation of ssh, includes ssh terminal and scp file copy. http://www.chiark.greenend.org.uk/~sgtatham/putty/
TeraTerm:
A popular freeware terminal program for Windows that includes optional SSH terminal session support.
http://hp.vector.co.jp/authors/VA002416/teraterm.html (TeraTerm home page)
http://www.zip.com.au/~roca/ttssh.html (SSH extension for TeraTerm)
WinSCP -- implements scp on Windows with an FTP-like GUI interface:
http://winscp.vse.cz/eng
A tutorial on setting up and using freeware SSH for windows: http://www.jfitz.com/tips/ssh_for_windows.html
A tutorial on using SSH for remote X sessions with FreeBSD:
http://www.defcon1.org/x11ssh.html
Explanation of how to use SSH to encrypt a VNC connection. Note that VNC does not normally encrypt connections, so it is susceptible to eavesdropping:
http://www.uk.research.att.com/vnc/sshvnc.html