+In SSH, you don't have to run a general shell session on the server.
+Instead, you can choose to run a single specific command (such as a
+mail user agent, for example). If you want to do this, enter the
+command in the \q{Remote command} box.
+
+\S{config-ssh-pty} \q{Don't allocate a pseudo-terminal}
+
+When connecting to a Unix system, most interactive shell sessions
+are run in a \e{pseudo-terminal}, which allows the Unix system to
+pretend it's talking to a real physical terminal device but allows
+the SSH server to catch all the data coming from that fake device
+and send it back to the client.
+
+Occasionally you might find you have a need to run a session \e{not}
+in a pseudo-terminal. In PuTTY, this is generally only useful for
+very specialist purposes; although in Plink (see \k{plink}) it is
+the usual way of working.
+
+\S{config-ssh-comp} \q{Enable compression}
+
+This enables data compression in the SSH connection: data sent by
+the server is compressed before sending, and decompressed at the
+client end. Likewise, data sent by PuTTY to the server is compressed
+first and the server decompresses it at the other end. This can help
+make the most of a low-bandwidth connection.
+
+\S{config-ssh-prot} \q{Preferred SSH protocol version}
+
+This allows you to select whether you would like to use SSH protocol
+version 1 or version 2. \#{FIXME: say something about this elsewhere?}
+
+PuTTY will attempt to use protocol 1 if the server you connect to
+does not offer protocol 2, and vice versa.
+
+\S{config-ssh-macbug} \q{Imitate SSH 2 MAC bug}
+
+This option \e{should} now be unnecessary. It existed in order to
+work around a bug in early versions (2.3.0 and below) of the SSH
+server software from \cw{ssh.com}. The symptom of this problem would
+be that PuTTY would die unexpectedly at the beginning of the
+session, saying \q{Incorrect MAC received on packet}.
+
+Current versions of PuTTY attempt to detect these faulty servers and
+enable the bug compatibility automatically, so you should never need
+to use this option any more.
+
+\S{config-ssh-encryption} Encryption algorithm selection
+
+PuTTY supports a variety of different encryption algorithms, and
+allows you to choose which one you prefer to use. You can do this by
+dragging the algorithms up and down in the list box to specify a
+preference order. When you make an SSH connection, PuTTY will search
+down the list from the top until it finds an algorithm supported by
+the server, and then use that.
+
+If the algorithm PuTTY finds is below the \q{warn below here} line,
+you will see a warning box when you make the connection:
+
+\c The first cipher supported by the server
+\c is single-DES, which is below the configured
+\c warning threshold.
+\c Do you want to continue with this connection?
+
+This warns you that the first available encryption is not a very
+secure one. Typically you would put the \q{warn below here} line
+between the encryptions you consider secure and the ones you
+consider substandard.
+
+By default, PuTTY supplies a preference order intended to reflect a
+reasonable preference in terms of security and speed.
+
+\H{config-ssh-auth} The Auth panel
+
+The Auth panel allows you to configure authentication options for
+SSH sessions.
+
+\S{config-ssh-tis} \q{Attempt TIS or CryptoCard authentication}
+
+TIS and CryptoCard authentication are simple challenge/response
+forms of authentication available in SSH protocol version 1 only.
+You might use them if you were using S/Key one-time passwords, for
+example, or if you had a physical security token that generated
+responses to authentication challenges.
+
+With this switch enabled, PuTTY will attempt these forms of
+authentication if the server is willing to try them. You will be
+presented with a challenge string (which will be different every
+time) and must supply the correct response in order to log in. If
+your server supports this, you should talk to your system
+administrator about precisely what form these challenges and
+responses take.
+
+\S{config-ssh-agentfwd} \q{Allow agent forwarding}
+
+This option allows the SSH server to open forwarded connections back
+to your local copy of Pageant. If you are not running Pageant, this
+option will do nothing.
+
+See \k{pageant} for general information on Pageant, and
+\k{pageant-forward} for information on agent forwarding. Note that
+there is a security risk involved with enabling this option; see
+\k{pageant-security} for details.
+
+\S{config-ssh-privkey} \q{Private key file for authentication}
+
+This box is where you enter the name of your private key file if you
+are using public key authentication. See \k{pubkey} for information
+about public key authentication in SSH.
+
+\H{config-ssh-tunnels} The Tunnels panel
+
+The Tunnels panel allows you to configure tunnelling of other
+connection types through an SSH connection.
+
+\S{config-ssh-x11} X11 forwarding
+
+If your server lets you run X Window System applications, X11
+forwarding allows you to securely give those applications access to
+a local X display on your PC.
+
+This feature will only be useful if you have an X server on your PC,
+such as Exceed or XWin32.
+
+To enable X11 forwarding, check the \q{Enable X11 forwarding} box.
+If your X display is not the primary display on your local machine
+(which it almost certainly will be unless you have deliberately
+arranged otherwise), you need to enter its location in the \q{X
+display location} box.
+
+\# FIXME: perhaps link to some more general X forwarding info?
+
+\S{config-ssh-portfwd} Port forwarding
+
+Port forwarding allows you to tunnel other types of network
+connection down an SSH connection.
+
+To set up a local port forwarding, make sure the \q{Local} radio
+button is set. Then enter a local port number (on your PC) in the
+\q{Source port} box, and a hostname and port number (separated by a
+colon) in the \q{Destination} box, and finally press the \q{Add}
+button. For example, you might select a source port of 10079, and a
+destination of \c{server2.example.com:79}.
+
+If you do this, and then start the session, you should find that
+connecting to your local PC on port 10079 gives you a connection to
+port 79 (the finger server) on \c{server2.example.com}. The
+connection is actually going to PuTTY itself, which encrypts the
+connection data and sends it down the secure channel to the SSH
+server. The connection then proceeds in clear from there to the
+eventual destination. So you might use this (for example) to forward
+a connection between two non-hostile network zones that are only
+connected by a hostile zone such as the open Internet.
+
+You can forward ports on the SSH server machine in the other
+direction, too (so the connection will start at the server end and
+be sent down the secure connection to PuTTY, which will make the
+real connection to the destination). To work this way round, just
+click the \q{Remote} radio button instead of \q{Local}.