-\versionid $Id: config.but,v 1.17 2001/12/06 13:28:02 simon Exp $
+\versionid $Id: config.but,v 1.47 2002/12/18 16:23:10 simon Exp $
\C{config} Configuring PuTTY
summary of the differences between SSH, Telnet and rlogin.)
\b The \q{Port} box lets you specify which port number on the server
-to connect to. If you select Telnet, Rlogin, or SSH, this box will be
-filled in automatically to the usual value, and you will only need to
-change it if you have an unusual server. If you select Raw mode, you
-will almost certainly need to fill in the \q{Port} box.
+to connect to. If you select Telnet, Rlogin, or SSH, this box will
+be filled in automatically to the usual value, and you will only
+need to change it if you have an unusual server. If you select Raw
+mode (see \k{using-rawprot}), you will almost certainly need to fill
+in the \q{Port} box.
\S{config-saving} Loading and storing saved sessions
else can replay the session later in slow motion and watch to see
what went wrong.
+\b \q{Log SSH packet data}. In this mode (which is only used by SSH
+connections), the SSH message packets sent over the encrypted
+connection are written to the log file. You might need this to debug
+a network-level problem, or more likely to send to the PuTTY authors
+as part of a bug report. \e{BE WARNED} that if you log in using a
+password, the password will appear in the log file, so be sure to
+edit it out before sending the log file to anyone else!
+
\S{config-logfilename} \q{Log file name}
\cfg{winhelp-topic}{logging.filename}
Auto wrap mode can be turned on and off by control sequences sent by
the server. This configuration option only controls the \e{default}
state. If you modify this option in mid-session using \q{Change
-Settings}, you will need to reset the terminal \#{ FIXME } before
-the change takes effect.
+Settings}, you will need to reset the terminal (see
+\k{reset-terminal}) before the change takes effect.
\S{config-decom} \q{DEC Origin Mode initially on}
like the wrong part of the screen, you could try turning DEC Origin
Mode on to see whether that helps.
-DEC Origin Mode can be turned on and off by control sequences sent by
-the server. This configuration option only controls the \e{default}
-state. If you modify this option in mid-session using \q{Change
-Settings}, you will need to reset the terminal \#{ FIXME } before
-the change takes effect.
+DEC Origin Mode can be turned on and off by control sequences sent
+by the server. This configuration option only controls the
+\e{default} state. If you modify this option in mid-session using
+\q{Change Settings}, you will need to reset the terminal (see
+\k{reset-terminal}) before the change takes effect.
\S{config-crlf} \q{Implicit CR in every LF}
default background colour. With this option enabled, it is done in
the \e{current} background colour.
+Background-colour erase can be turned on and off by control
+sequences sent by the server. This configuration option only
+controls the \e{default} state. If you modify this option in
+mid-session using \q{Change Settings}, you will need to reset the
+terminal (see \k{reset-terminal}) before the change takes effect.
+
\S{config-blink} \q{Enable blinking text}
\cfg{winhelp-topic}{terminal.blink}
This is very distracting, so PuTTY allows you to turn blinking text
off completely.
+When blinking text is disabled and the server attempts to make some
+text blink, PuTTY will instead display the text with a bolded
+background colour.
+
+Blinking text can be turned on and off by control sequences sent by
+the server. This configuration option only controls the \e{default}
+state. If you modify this option in mid-session using \q{Change
+Settings}, you will need to reset the terminal (see
+\k{reset-terminal}) before the change takes effect.
+
\S{config-answerback} \q{Answerback to ^E}
\cfg{winhelp-topic}{terminal.answerback}
server sends it the ^E enquiry character. Normally it just sends
the string \q{PuTTY}.
+If you accidentally write the contents of a binary file to your
+terminal, you will probably find that it contains more than one ^E
+character, and as a result your next command line will probably read
+\q{PuTTYPuTTYPuTTY...} as if you had typed the answerback string
+multiple times at the keyboard. If you set the answerback string to
+be empty, this problem should go away, but doing so might cause
+other problems.
+
+Note that this is \e{not} the feature of PuTTY which the server will
+typically use to determine your terminal type. That feature is the
+\q{Terminal-type string} in the Connection panel; see
+\k{config-termtype} for details.
+
+You can include control characters in the answerback string using
+\c{^C} notation. (Use \c{^~} to get a literal \c{^}.)
+
\S{config-localecho} \q{Local echo}
\cfg{winhelp-topic}{terminal.localecho}
local line editing to be turned on, or force it to be turned off,
instead of relying on the automatic detection.
+\S{config-printing} Remote-controlled printing
+
+\cfg{winhelp-topic}{terminal.printing}
+
+A lot of VT100-compatible terminals support printing under control
+of the remote server. PuTTY supports this feature as well, but it is
+turned off by default.
+
+To enable remote-controlled printing, choose a printer from the
+\q{Printer to send ANSI printer output to} drop-down list box. This
+should allow you to select from all the printers you have installed
+drivers for on your computer. Alternatively, you can type the
+network name of a networked printer (for example,
+\c{\\\\printserver\\printer1}) even if you haven't already
+installed a driver for it on your own machine.
+
+When the remote server attempts to print some data, PuTTY will send
+that data to the printer \e{raw} - without translating it,
+attempting to format it, or doing anything else to it. It is up to
+you to ensure your remote server knows what type of printer it is
+talking to.
+
+Since PuTTY sends data to the printer raw, it cannot offer options
+such as portrait versus landscape, print quality, or paper tray
+selection. All these things would be done by your PC printer driver
+(which PuTTY bypasses); if you need them done, you will have to find
+a way to configure your remote server to do them.
+
+To disable remote printing again, choose \q{None (printing
+disabled)} from the printer selection list. This is the default
+state.
+
\H{config-keyboard} The Keyboard panel
The Keyboard configuration panel allows you to control the behaviour
Application Cursor Keys mode can be turned on and off by the server,
depending on the application. PuTTY allows you to configure the
-initial state, and also allows you to disable application mode
-completely.
+initial state.
+
+You can also disable application cursor keys mode completely, using
+the \q{Features} configuration panel; see
+\k{config-features-application}.
\S{config-appkeypad} Controlling Application Keypad mode
Application keypad mode can be turned on and off by the server,
depending on the application. PuTTY allows you to configure the
-initial state, and also allows you to disable application mode
-completely.
+initial state.
+
+You can also disable application keypad mode completely, using the
+\q{Features} configuration panel; see
+\k{config-features-application}.
\S{config-nethack} Using NetHack keypad mode
easy to remember; for example, composing \q{e} and \q{`} produces
the \q{\u00e8{e-grave}} character.
-If you enable the \q{Application and AltGr act as Compose key}
-option, the Windows Application key and the AltGr key will both have
-this behaviour.
+If your keyboard has a Windows Application key, it acts as a Compose
+key in PuTTY. Alternatively, if you enable the \q{AltGr acts as
+Compose key} option, the AltGr key will become a Compose key.
\S{config-ctrlalt} \q{Control-Alt is different from AltGr}
so you can use it to type extra graphic characters if your keyboard
has any.
+(However, Ctrl-Alt will never act as a Compose key, regardless of the
+setting of \q{AltGr acts as Compose key} described in
+\k{config-compose}.)
+
\H{config-bell} The Bell panel
The Bell panel controls the terminal bell feature: the server's
in to do so, and how much silent time is required before the
overload feature will deactivate itself.
+Bell overload mode is always deactivated by any keypress in the
+terminal. This means it can respond to large unexpected streams of
+data, but does not interfere with ordinary command-line activities
+that generate beeps (such as filename completion).
+
+\H{config-features} The Features panel
+
+PuTTY's terminal emulation is very highly featured, and can do a lot
+of things under remote server control. Some of these features can
+cause problems due to buggy or strangely configured server
+applications.
+
+The Features configuration panel allows you to disable some of
+PuTTY's more advanced terminal features, in case they cause trouble.
+
+\S{config-features-application} Disabling application keypad and cursor keys
+
+\cfg{winhelp-topic}{features.application}
+
+Application keypad mode (see \k{config-appkeypad}) and application
+cursor keys mode (see \k{config-appcursor}) alter the behaviour of
+the keypad and cursor keys. Some applications enable these modes but
+then do not deal correctly with the modified keys. You can force
+these modes to be permanently disabled no matter what the server
+tries to do.
+
+\S{config-features-mouse} Disabling \cw{xterm}-style mouse reporting
+
+\cfg{winhelp-topic}{features.mouse}
+
+PuTTY allows the server to send control codes that let it take over
+the mouse and use it for purposes other than copy and paste.
+Applications which use this feature include the text-mode web
+browser \c{links}, the Usenet newsreader \c{trn} version 4, and the
+file manager \c{mc} (Midnight Commander).
+
+If you find this feature inconvenient, you can disable it using the
+\q{Disable xterm-style mouse reporting} control. With this box
+ticked, the mouse will \e{always} do copy and paste in the normal
+way.
+
+Note that even if the application takes over the mouse, you can
+still manage PuTTY's copy and paste by holding down the Shift key
+while you select and paste, unless you have deliberately turned this
+feature off (see \k{config-mouseshift}).
+
+\S{config-features-resize} Disabling remote terminal resizing
+
+\cfg{winhelp-topic}{features.resize}
+
+PuTTY has the ability to change the terminal's size and position in
+response to commands from the server. If you find PuTTY is doing
+this unexpectedly or inconveniently, you can tell PuTTY not to
+respond to those server commands.
+
+\S{config-features-altscreen} Disabling switching to the alternate screen
+
+\cfg{winhelp-topic}{features.altscreen}
+
+Many terminals, including PuTTY, support an \q{alternate screen}.
+This is the same size as the ordinary terminal screen, but separate.
+Typically a screen-based program such as a text editor might switch
+the terminal to the alternate screen before starting up. Then at the
+end of the run, it switches back to the primary screen, and you see
+the screen contents just as they were before starting the editor.
+
+Some people prefer this not to happen. If you want your editor to
+run in the same screen as the rest of your terminal activity, you
+can disable the alternate screen feature completely.
+
+\S{config-features-retitle} Disabling remote window title changing
+
+\cfg{winhelp-topic}{features.retitle}
+
+PuTTY has the ability to change the window title in response to
+commands from the server. If you find PuTTY is doing this
+unexpectedly or inconveniently, you can tell PuTTY not to respond to
+those server commands.
+
+\S{config-features-dbackspace} Disabling destructive backspace
+
+\cfg{winhelp-topic}{features.dbackspace}
+
+Normally, when PuTTY receives character 127 (^?) from the server, it
+will perform a \q{destructive backspace}: move the cursor one space
+left and delete the character under it. This can apparently cause
+problems in some applications, so PuTTY provides the ability to
+configure character 127 to perform a normal backspace (without
+deleting a character) instead.
+
+\S{config-features-charset} Disabling remote character set
+configuration
+
+\cfg{winhelp-topic}{features.charset}
+
+PuTTY has the ability to change its character set configuration in
+response to commands from the server. Some programs send these
+commands unexpectedly or inconveniently. In particular, BitchX (an
+IRC client) seems to have a habit of reconfiguring the character set
+to something other than the user intended.
+
+If you find that accented characters are not showing up the way you
+expect them to, particularly if you're running BitchX, you could try
+disabling the remote character set configuration commands.
+
\H{config-window} The Window panel
The Window configuration panel allows you to control aspects of the
\cfg{winhelp-topic}{behaviour.altenter}
If this option is enabled, then pressing Alt-Enter will cause the
-PuTTY window to become full-screen. (See \k{using-fullscreen}).
-Pressing Alt-Enter again will restore the previous window size.
+PuTTY window to become full-screen. Pressing Alt-Enter again will
+restore the previous window size.
+
+The full-screen feature is also available from the System menu, even
+when it is configured not to be available on the Alt-Enter key. See
+\k{using-fullscreen}.
\H{config-translation} The Translation panel
If you select \q{UTF-8} as a character set you can use this mode.
Not all server-side applications will support it.
+If you need support for a numeric code page which is not listed in
+the drop-down list, such as code page 866, then you should be able
+to enter its name manually (\c{CP866} for example) in the list box
+and get the right result.
+
\S{config-cyr} \q{Caps Lock acts as Cyrillic switch}
\cfg{winhelp-topic}{translation.cyrillic}
checkbox will cause Shift + mouse clicks to go to the server as well
(so that mouse-driven copy and paste will be completely disabled).
+If you want to prevent the application from taking over the mouse at
+all, you can do this using the Features control panel; see
+\k{config-features-mouse}.
+
\S{config-rectselect} Default selection mode
\cfg{winhelp-topic}{selection.rect}
This mechanism currently only covers ASCII characters, because it
isn't feasible to expand the list to cover the whole of Unicode.
+Character class definitions can be modified by control sequences
+sent by the server. This configuration option only controls the
+\e{default} state. If you modify this option in mid-session using
+\q{Change Settings}, you will need to reset the terminal (see
+\k{reset-terminal}) before the change takes effect.
+
\H{config-colours} The Colours panel
The Colours panel allows you to control PuTTY's use of colour.
Keepalives are only supported in Telnet and SSH; the Rlogin and Raw
protocols offer no way of implementing them.
+Note that if you are using SSH1 and the server has a bug that makes
+it unable to deal with SSH1 ignore messages (see
+\k{config-ssh-bug-ignore1}), enabling keepalives will have no effect.
+
\S{config-nodelay} \q{Disable Nagle's algorithm}
\cfg{winhelp-topic}{connection.nodelay}
The Nagle algorithm is disabled by default.
+\H{config-proxy} The Proxy panel
+
+\cfg{winhelp-topic}{proxy.main}
+
+The Proxy panel allows you to configure PuTTY to use various types
+of proxy in order to make its network connections. The settings in
+this panel affect the primary network connection forming your PuTTY
+session, but also any extra connections made as a result of SSH port
+forwarding (see \k{using-port-forwarding}).
+
+\S{config-proxy-type} Setting the proxy type
+
+\cfg{winhelp-topic}{proxy.type}
+
+The \q{Proxy type} radio buttons allow you to configure what type of
+proxy you want PuTTY to use for its network connections. The default
+setting is \q{None}; in this mode no proxy is used for any
+connection.
+
+\b Selecting \q{HTTP} allows you to proxy your connections through a
+web server supporting the HTTP \cw{CONNECT} command, as documented
+in \W{http://www.ietf.org/rfc/rfc2817.txt}{RFC 2817}.
+
+\b Selecting \q{SOCKS} allows you to proxy your connections through
+a SOCKS server.
+
+\b Many firewalls implement a less formal type of proxy in which a
+user can make a Telnet connection directly to the firewall machine
+and enter a command such as \c{connect myhost.com 22} to connect
+through to an external host. Selecting \q{Telnet} allows you to tell
+PuTTY to use this type of proxy.
+
+\S{config-proxy-exclude} Excluding parts of the network from proxying
+
+\cfg{winhelp-topic}{proxy.exclude}
+
+Typically you will only need to use a proxy to connect to non-local
+parts of your network; for example, your proxy might be required for
+connections outside your company's internal network. In the
+\q{Exclude Hosts/IPs} box you can enter ranges of IP addresses, or
+ranges of DNS names, for which PuTTY will avoid using the proxy and
+make a direct connection instead.
+
+The \q{Exclude Hosts/IPs} box may contain more than one exclusion
+range, separated by commas. Each range can be an IP address or a DNS
+name, with a \c{*} character allowing wildcards. For example:
+
+\c *.example.com
+
+This excludes any host with a name ending in \c{.example.com} from
+proxying.
+
+\c 192.168.88.*
+
+This excludes any host with an IP address starting with 192.168.88
+from proxying.
+
+\c 192.168.88.*,*.example.com
+
+This excludes both of the above ranges at once.
+
+Connections to the local host (the host name \c{localhost}, and any
+loopback IP address) are never proxied, even if the proxy exclude
+list does not explicitly contain them. It is very unlikely that this
+behaviour would ever cause problems, but if it does you can change
+it by enabling \q{Consider proxying local host connections}.
+
+Note that if you are doing DNS at the proxy (see
+\k{config-proxy-dns}), you should make sure that your proxy
+exclusion settings do not depend on knowing the IP address of a
+host. If the name is passed on to the proxy without PuTTY looking it
+up, it will never know the IP address and cannot check it against
+your list.
+
+\S{config-proxy-dns} Name resolution when using a proxy
+
+\cfg{winhelp-topic}{proxy.dns}
+
+If you are using a proxy to access a private network, it can make a
+difference whether DNS name resolution is performed by PuTTY itself
+(on the client machine) or performed by the proxy.
+
+The \q{Do DNS name lookup at proxy end} configuration option allows
+you to control this. If you set it to \q{No}, PuTTY will always do
+its own DNS, and will always pass an IP address to the proxy. If you
+set it to \q{Yes}, PuTTY will always pass host names straight to the
+proxy without trying to look them up first.
+
+If you set this option to \q{Auto} (the default), PuTTY will do
+something it considers appropriate for each type of proxy. Telnet
+and HTTP proxies will have host names passed straight to them; SOCKS
+proxies will not.
+
+Note that if you are doing DNS at the proxy, you should make sure
+that your proxy exclusion settings (see \k{config-proxy-exclude}) do
+not depend on knowing the IP address of a host. If the name is
+passed on to the proxy without PuTTY looking it up, it will never
+know the IP address and cannot check it against your list.
+
+The original SOCKS 4 protocol does not support proxy-side DNS. There
+is a protocol extension (SOCKS 4A) which does support it, but not
+all SOCKS 4 servers provide this extension. If you enable proxy DNS
+and your SOCKS 4 server cannot deal with it, this might be why.
+
+\S{config-proxy-auth} Username and password
+
+\cfg{winhelp-topic}{proxy.auth}
+
+If your proxy requires authentication, you can enter a username and
+a password in the \q{Username} and \q{Password} boxes.
+
+Authentication is not supported for all forms of proxy:
+
+\b Username and password authentication is supported for HTTP
+proxies and SOCKS 5 proxies.
+
+\b SOCKS 4 can use the \q{Username} field, but does not support
+passwords.
+
+\b You can specify a way to include a username and password in the
+Telnet proxy command (see \k{config-proxy-command}).
+
+\S{config-proxy-command} Specifying the Telnet proxy command
+
+\cfg{winhelp-topic}{proxy.command}
+
+If you are using the Telnet proxy type, the usual command required
+by the firewall's Telnet server is \c{connect}, followed by a host
+name and a port number. If your proxy needs a different command,
+you can enter an alternative here.
+
+In this string, you can use \c{\\n} to represent a new-line, \c{\\r}
+to represent a carriage return, \c{\\t} to represent a tab
+character, and \c{\\x} followed by two hex digits to represent any
+other character. \c{\\\\} is used to encode the \c{\\} character
+itself.
+
+Also, the special strings \c{%host} and \c{%port} will be replaced
+by the host name and port number you want to connect to. The strings
+\c{%user} and \c{%pass} will be replaced by the proxy username and
+password you specify. To get a literal \c{%} sign, enter \c{%%}.
+
+If the Telnet proxy server prompts for a username and password
+before commands can be sent, you can use a command such as:
+
+\c %user\\n%pass\\nconnect %host %port\\n
+
+This will send your username and password as the first two lines to
+the proxy, followed by a command to connect to the desired host and
+port. Note that if you do not include the \c{%user} or \c{%pass}
+tokens in the Telnet command, then the \q{Username} and \q{Password}
+configuration fields will be ignored.
+
+\S{config-proxy-socksver} Selecting the version of the SOCKS protocol
+
+\cfg{winhelp-topic}{proxy.socksver}
+
+SOCKS servers exist in two versions: version 5
+(\W{http://www.ietf.org/rfc/rfc1928.txt}{RFC 1928}) and the earlier
+version 4. The \q{SOCKS Version} radio buttons allow you to select
+which one to use, if you have selected the SOCKS proxy type.
+
\H{config-telnet} The Telnet panel
The Telnet panel allows you to configure options that only apply to
Telnet special interrupt code. You probably shouldn't enable this
unless you know what you're doing.
+\S{config-telnetnl} \q{Return key sends telnet New Line instead of ^M}
+
+\cfg{winhelp-topic}{telnet.newline}
+
+Unlike most other remote login protocols, the Telnet protocol has a
+special \q{new line} code that is not the same as the usual line
+endings of Control-M or Control-J. By default, PuTTY sends the
+Telnet New Line code when you press Return, instead of sending
+Control-M as it does in most other protocols.
+
+Most Unix-style Telnet servers don't mind whether they receive
+Telnet New Line or Control-M; some servers do expect New Line, and
+some servers prefer to see ^M. If you are seeing surprising
+behaviour when you press Return in a Telnet session, you might try
+turning this option off to see if it helps.
+
\H{config-rlogin} The Rlogin panel
The Rlogin panel allows you to configure options that only apply to
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}
-
-\cfg{winhelp-topic}{ssh.buggymac}
-
-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.
+If you select \q{1 only} or \q{2 only} here, PuTTY will only connect
+if the server you connect to offers the SSH protocol version you
+have specified.
\S{config-ssh-encryption} Encryption algorithm selection
intended to reflect a reasonable preference in terms of security and
speed.
+In SSH-2, the encryption algorithm is negotiated independently for
+each direction of the connection, although PuTTY does not support
+separate configuration of the preference orders. As a result you may
+get two warnings similar to the one above, possibly with different
+encryptions.
+
Single-DES is not supported natively in the SSH 2 draft protocol
standards. One or two server implementations do support it, by a
non-standard name. PuTTY can use single-DES to interoperate with
administrator about precisely what form these challenges and
responses take.
-\S{config-ssh-tis} \q{Attempt keyboard-interactive authentication}
+\S{config-ssh-ki} \q{Attempt keyboard-interactive authentication}
\cfg{winhelp-topic}{ssh.auth.ki}
there is a security risk involved with enabling this option; see
\k{pageant-security} for details.
+\S{config-ssh-changeuser} \q{Allow attempted changes of username in SSH2}
+
+\cfg{winhelp-topic}{ssh.auth.changeuser}
+
+In the SSH 1 protocol, it is impossible to change username after
+failing to authenticate. So if you mis-type your username at the
+PuTTY \q{login as:} prompt, you will not be able to change it except
+by restarting PuTTY.
+
+The SSH 2 protocol \e{does} allow changes of username, in principle,
+but does not make it mandatory for SSH 2 servers to accept them. In
+particular, OpenSSH does not accept a change of username; once you
+have sent one username, it will reject attempts to try to
+authenticate as another user. (Depending on the version of OpenSSH,
+it may quietly return failure for all login attempts, or it may send
+an error message.)
+
+For this reason, PuTTY will by default not prompt you for your
+username more than once, in case the server complains. If you know
+your server can cope with it, you can enable the \q{Allow attempted
+changes of username} option to modify PuTTY's behaviour.
+
\S{config-ssh-privkey} \q{Private key file for authentication}
\cfg{winhelp-topic}{ssh.auth.privkey}
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?
+See \k{using-x-forwarding} for more information about X11
+forwarding.
\S{config-ssh-portfwd} Port forwarding
\cfg{winhelp-topic}{ssh.tunnels.portfwd}
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}.
-
-\# FIXME: perhaps move this to a general port-forwarding section and
-\# just link to it here?
+connection down an SSH session. See \k{using-port-forwarding} for a
+general discussion of port forwarding and how it works.
+
+The port forwarding section in the Tunnels panel shows a list of all
+the port forwardings that PuTTY will try to set up when it connects
+to the server. By default no port forwardings are set up, so this
+list is empty.
+
+To add a port forwarding:
+
+\b Set one of the \q{Local} or \q{Remote} radio buttons, depending
+on whether you want to forward a local port to a remote destination
+(\q{Local}) or forward a remote port to a local destination
+(\q{Remote}).
+
+\b Enter a source port number into the \q{Source port} box. For
+local forwardings, PuTTY will listen on this port of your PC. For
+remote forwardings, your SSH server will listen on this port of the
+remote machine. Note that most servers will not allow you to listen
+on port numbers less than 1024.
+
+\b Enter a hostname and port number separated by a colon, in the
+\q{Destination} box. Connections received on the source port will be
+directed to this destination. For example, to connect to a POP-3
+server, you might enter \c{popserver.example.com:110}.
+
+\b Click the \q{Add} button. Your forwarding details should appear
+in the list box.
+
+To remove a port forwarding, simply select its details in the list
+box, and click the \q{Remove} button.
+
+In the \q{Source port} box, you can also optionally enter an IP
+address to listen on. Typically a Windows machine can be asked to
+listen on any single IP address in the \cw{127.*.*.*} range, and all
+of these are loopback addresses available only to the local machine.
+So if you forward (for example) \c{127.0.0.5:79} to a remote
+machine's \cw{finger} port, then you should be able to run commands
+such as \c{finger fred@127.0.0.5}. This can be useful if the program
+connecting to the forwarded port doesn't allow you to change the
+port number it uses. This feature is available for local-to-remote
+forwarded ports; SSH1 is unable to support it for remote-to-local
+ports, while SSH2 can support it in theory but servers will not
+necessarily cooperate.
+
+\S{config-ssh-portfwd-localhost} Controlling the visibility of
+forwarded ports
+
+\cfg{winhelp-topic}{ssh.tunnels.portfwd.localhost}
+
+The source port for a forwarded connection usually does not accept
+connections from any machine except the SSH client or server machine
+itself (for local and remote forwardings respectively). There are
+controls in the Tunnels panel to change this:
+
+\b The \q{Local ports accept connections from other hosts} option
+allows you to set up local-to-remote port forwardings in such a way
+that machines other than your client PC can connect to the forwarded
+port.
+
+\b The \q{Remote ports do the same} option does the same thing for
+remote-to-local port forwardings (so that machines other than the
+SSH server machine can connect to the forwarded port.) Note that
+this feature is only available in the SSH 2 protocol, and not all
+SSH 2 servers support it (OpenSSH 3.0 does not, for example).
+
+\H{config-ssh-bugs} The Bugs panel
+
+Not all SSH servers work properly. Various existing servers have
+bugs in them, which can make it impossible for a client to talk to
+them unless it knows about the bug and works around it.
+
+Since most servers announce their software version number at the
+beginning of the SSH connection, PuTTY will attempt to detect which
+bugs it can expect to see in the server and automatically enable
+workarounds. However, sometimes it will make mistakes; if the server
+has been deliberately configured to conceal its version number, or
+if the server is a version which PuTTY's bug database does not know
+about, then PuTTY will not know what bugs to expect.
+
+The Bugs panel allows you to manually configure the bugs PuTTY
+expects to see in the server. Each bug can be configured in three
+states:
+
+\b \q{Off}: PuTTY will assume the server does not have the bug.
+
+\b \q{On}: PuTTY will assume the server \e{does} have the bug.
+
+\b \q{Auto}: PuTTY will use the server's version number announcement
+to try to guess whether or not the server has the bug.
+
+\S{config-ssh-bug-ignore1} \q{Chokes on SSH1 ignore messages}
+
+\cfg{winhelp-topic}{ssh.bugs.ignore1}
+
+An ignore message (SSH_MSG_IGNORE) is a message in the SSH protocol
+which can be sent from the client to the server, or from the server
+to the client, at any time. Either side is required to ignore the
+message whenever it receives it. PuTTY uses ignore messages to hide
+the password packet in SSH1, so that a listener cannot tell the
+length of the user's password; it also uses ignore messages for
+connection keepalives (see \k{config-keepalive}).
+
+If this bug is detected, PuTTY will stop using ignore messages. This
+means that keepalives will stop working, and PuTTY will have to fall
+back to a secondary defence against SSH1 password-length
+eavesdropping. See \k{config-ssh-bug-plainpw1}. If this bug is
+enabled when talking to a correct server, the session will succeed,
+but keepalives will not work and the session might be more
+vulnerable to eavesdroppers than it could be.
+
+This is an SSH1-specific bug. No known SSH2 server fails to deal
+with SSH2 ignore messages.
+
+\S{config-ssh-bug-plainpw1} \q{Refuses all SSH1 password camouflage}
+
+\cfg{winhelp-topic}{ssh.bugs.plainpw1}
+
+When talking to an SSH1 server which cannot deal with ignore
+messages (see \k{config-ssh-bug-ignore1}), PuTTY will attempt to
+disguise the length of the user's password by sending additional
+padding \e{within} the password packet. This is technically a
+violation of the SSH1 specification, and so PuTTY will only do it
+when it cannot use standards-compliant ignore messages as
+camouflage. In this sense, for a server to refuse to accept a padded
+password packet is not really a bug, but it does make life
+inconvenient if the server can also not handle ignore messages.
+
+If this \q{bug} is detected, PuTTY will have no choice but to send
+the user's password with no form of camouflage, so that an
+eavesdropping user will be easily able to find out the exact length
+of the password. If this bug is enabled when talking to a correct
+server, the session will succeed, but will be more vulnerable to
+eavesdroppers than it could be.
+
+This is an SSH1-specific bug. SSH2 is secure against this type of
+attack.
+
+\S{config-ssh-bug-rsa1} \q{Chokes on SSH1 RSA authentication}
+
+\cfg{winhelp-topic}{ssh.bugs.rsa1}
+
+Some SSH1 servers cannot deal with RSA authentication messages at
+all. If Pageant is running and contains any SSH1 keys, PuTTY will
+normally automatically try RSA authentication before falling back to
+passwords, so these servers will crash when they see the RSA attempt.
+
+If this bug is detected, PuTTY will go straight to password
+authentication. If this bug is enabled when talking to a correct
+server, the session will succeed, but of course RSA authentication
+will be impossible.
+
+This is an SSH1-specific bug.
+
+\S{config-ssh-bug-hmac2} \q{Miscomputes SSH2 HMAC keys}
+
+\cfg{winhelp-topic}{ssh.bugs.hmac2}
+
+Versions 2.3.0 and below of the SSH server software from
+\cw{ssh.com} compute the keys for their HMAC message authentication
+codes incorrectly. A typical symptom of this problem is that PuTTY
+dies unexpectedly at the beginning of the session, saying
+\q{Incorrect MAC received on packet}.
+
+If this bug is detected, PuTTY will compute its HMAC keys in the
+same way as the buggy server, so that communication will still be
+possible. If this bug is enabled when talking to a correct server,
+communication will fail.
+
+This is an SSH2-specific bug.
+
+\S{config-ssh-bug-derivekey2} \q{Miscomputes SSH2 encryption keys}
+
+\cfg{winhelp-topic}{ssh.bugs.derivekey2}
+
+Versions below 2.1.0 of the SSH server software from \cw{ssh.com}
+compute the keys for the session encryption incorrectly. This
+problem can cause various error messages, such as \q{Incoming packet
+was garbled on decryption}, or possibly even \q{Out of memory}.
+
+If this bug is detected, PuTTY will compute its encryption keys in
+the same way as the buggy server, so that communication will still
+be possible. If this bug is enabled when talking to a correct
+server, communication will fail.
+
+This is an SSH2-specific bug.
+
+\S{config-ssh-bug-sig} \q{Requires padding on SSH2 RSA signatures}
+
+\cfg{winhelp-topic}{ssh.bugs.rsapad2}
+
+Versions below 3.3 of OpenSSH require SSH2 RSA signatures to be
+padded with zero bytes to the same length as the RSA key modulus.
+The SSH2 draft specification says that an unpadded signature MUST be
+accepted, so this is a bug. A typical symptom of this problem is
+that PuTTY mysteriously fails RSA authentication once in every few
+hundred attempts, and falls back to passwords.
+
+If this bug is detected, PuTTY will pad its signatures in the way
+OpenSSH expects. If this bug is enabled when talking to a correct
+server, it is likely that no damage will be done, since correct
+servers usually still accept padded signatures because they're used
+to talking to OpenSSH.
+
+This is an SSH2-specific bug.
+
+\S{config-ssh-bug-dhgex} \q{Chokes on Diffie-Hellman group exchange}
+
+\cfg{winhelp-topic}{ssh.bugs.dhgex2}
+
+We have anecdotal evidence that some SSH servers claim to be able to
+perform Diffie-Hellman group exchange, but fail to actually do so
+when PuTTY tries to. If your SSH2 sessions spontaneously close
+immediately after opening the PuTTY window, it might be worth
+enabling the workaround for this bug to see if it helps.
+
+We have no hard evidence that any specific version of specific
+server software reliably demonstrates this bug. Therefore, PuTTY
+will never \e{assume} a server has this bug; if you want the
+workaround, you need to enable it manually.
+
+This is an SSH2-specific bug.
\H{config-file} Storing configuration in a file
projects / u / mdw / putty / blobdiff