Add another bug workaround, this one for old OpenSSH (<2.3) servers
[u/mdw/putty] / doc / config.but
index 8992638..77a5566 100644 (file)
@@ -1,4 +1,4 @@
-\versionid $Id: config.but,v 1.44 2002/10/22 09:40:38 simon Exp $
+\versionid $Id: config.but,v 1.54 2003/02/04 13:02:51 simon Exp $
 
 \C{config} Configuring PuTTY
 
@@ -214,10 +214,11 @@ find the screen scrolling up when it looks as if it shouldn't, you
 could try turning this option off.
 
 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 (see
-\k{reset-terminal}) before the change takes effect.
+the server. This configuration option controls the \e{default}
+state, which will be restored when you reset the terminal (see
+\k{reset-terminal}). However, if you modify this option in
+mid-session using \q{Change Settings}, it will take effect
+immediately.
 
 \S{config-decom} \q{DEC Origin Mode initially on}
 
@@ -243,10 +244,11 @@ 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 (see
-\k{reset-terminal}) before the change takes effect.
+by the server. This configuration option controls the \e{default}
+state, which will be restored when you reset the terminal (see
+\k{reset-terminal}). However, if you modify this option in
+mid-session using \q{Change Settings}, it will take effect
+immediately.
 
 \S{config-crlf} \q{Implicit CR in every LF}
 
@@ -291,10 +293,11 @@ 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.
+sequences sent by the server. This configuration option controls the
+\e{default} state, which will be restored when you reset the
+terminal (see \k{reset-terminal}). However, if you modify this
+option in mid-session using \q{Change Settings}, it will take effect
+immediately.
 
 \S{config-blink} \q{Enable blinking text}
 
@@ -309,10 +312,11 @@ 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.
+the server. This configuration option controls the \e{default}
+state, which will be restored when you reset the terminal (see
+\k{reset-terminal}). However, if you modify this option in
+mid-session using \q{Change Settings}, it will take effect
+immediately.
 
 \S{config-answerback} \q{Answerback to ^E}
 
@@ -894,14 +898,16 @@ modify the title of the window in mid-session. There is also an
 This makes sense in a windowing system where the window becomes an
 icon when minimised, such as Windows 3.1 or most X Window System
 setups; but in the Windows 95-like user interface it isn't as
-applicable. By default PuTTY's window title and Taskbar caption will
+applicable.
+
+By default, PuTTY only uses the server-supplied \e{window} title, and
+ignores the icon title entirely. If for some reason you want to see
+both titles, check the box marked \q{Separate window and icon titles}.
+If you do this, PuTTY's window title and Taskbar caption will
 change into the server-supplied icon title if you minimise the PuTTY
 window, and change back to the server-supplied window title if you
 restore it. (If the server has not bothered to supply a window or
-icon title, none of this will happen.) By checking the box marked
-\q{Avoid ever using icon title}, you can arrange that PuTTY will
-always display the window title, and completely ignore any icon
-titles the server sends it.
+icon title, none of this will happen.)
 
 \S{config-mouseptr} \q{Hide mouse pointer when typing in window}
 
@@ -1224,10 +1230,11 @@ 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.
+sent by the server. This configuration option controls the
+\e{default} state, which will be restored when you reset the
+terminal (see \k{reset-terminal}). However, if you modify this
+option in mid-session using \q{Change Settings}, it will take effect
+immediately.
 
 \H{config-colours} The Colours panel
 
@@ -1275,9 +1282,10 @@ colour to go in place of the old one.
 PuTTY allows you to set the cursor colour, the default foreground
 and background, and the precise shades of all the ANSI configurable
 colours (black, red, green, yellow, blue, magenta, cyan, and white).
-In addition, if you have selected \q{Bolded text is a different
-colour}, you can also modify the precise shades used for the bold
-versions of these colours.
+You can also modify the precise shades used for the bold versions of
+these colours; these are used to display bold text if you have
+selected \q{Bolded text is a different colour}, and can also be used
+if the server asks specifically to use them.
 
 \H{config-connection} The Connection panel
 
@@ -1439,6 +1447,49 @@ from proxying.
 
 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}
@@ -1446,7 +1497,7 @@ This excludes both of the above ranges at once.
 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:
+Authentication is not fully supported for all forms of proxy:
 
 \b Username and password authentication is supported for HTTP
 proxies and SOCKS 5 proxies.
@@ -1480,7 +1531,7 @@ 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
+\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 
@@ -1822,6 +1873,8 @@ 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.
 
+This key must be in PuTTY's native format (\c{*.PPK}).
+
 \H{config-ssh-tunnels} The Tunnels panel
 
 The Tunnels panel allows you to configure tunnelling of other
@@ -1844,6 +1897,53 @@ display location} box.
 See \k{using-x-forwarding} for more information about X11
 forwarding.
 
+\S2{config-ssh-x11auth} Remote X11 authentication
+
+\cfg{winhelp-topic}{ssh.tunnels.x11auth}
+
+If you are using X11 forwarding, the virtual X server created on the
+SSH server machine will be protected by authorisation data. This
+data is invented, and checked, by PuTTY.
+
+The usual authorisation method used for this is called
+\cw{MIT-MAGIC-COOKIE-1}. This is a simple password-style protocol:
+the X client sends some cookie data to the server, and the server
+checks that it matches the real cookie. The cookie data is sent over
+an unencrypted X11 connection; so if you allow a client on a third
+machine to access the virtual X server, then the cookie will be sent
+in the clear.
+
+PuTTY offers the alternative protocol \cw{XDM-AUTHORIZATION-1}. This
+is a cryptographically authenticated protocol: the data sent by the
+X client is different every time, and it depends on the IP address
+and port of the client's end of the connection and is also stamped
+with the current time. So an eavesdropper who captures an
+\cw{XDM-AUTHORIZATION-1} string cannot immediately re-use it for
+their own X connection.
+
+PuTTY's support for \cw{XDM-AUTHORIZATION-1} is a somewhat
+experimental feature, and may encounter several problems:
+
+\b Some X clients probably do not even support
+\cw{XDM-AUTHORIZATION-1}, so they will not know what to do with the
+data PuTTY has provided.
+
+\b This authentication mechanism will only work in SSH v2. In SSH
+v1, the SSH server does not tell the client the source address of
+a forwarded connection in a machine-readable format, so it's
+impossible to verify the \cw{XDM-AUTHORIZATION-1} data.
+
+\b You may find this feature causes problems with some SSH servers,
+which will not clean up \cw{XDM-AUTHORIZATION-1} data after a
+session, so that if you then connect to the same server using
+a client which only does \cw{MIT-MAGIC-COOKIE-1} and are allocated
+the same remote display number, you might find that out-of-date
+authentication data is still present on your server and your X
+connections fail.
+
+PuTTY's default is \cw{MIT-MAGIC-COOKIE-1}. If you change it, you
+should be sure you know what you're doing.
+
 \S{config-ssh-portfwd} Port forwarding
 
 \cfg{winhelp-topic}{ssh.tunnels.portfwd}
@@ -1881,6 +1981,19 @@ 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
 
@@ -2059,6 +2172,24 @@ workaround, you need to enable it manually.
 
 This is an SSH2-specific bug.
 
+\S{config-ssh-bug-pksessid2} \q{Misuses the session ID in PK auth}
+
+\cfg{winhelp-topic}{ssh.bugs.rsapad2}
+
+Versions below 2.3 of OpenSSH require SSH2 public-key authentication
+to be done slightly differently: the data to be signed by the client
+contains the session ID formatted in a different way. If public-key
+authentication mysteriously does not work but the Event Log (see
+\k{using-eventlog}) thinks it has successfully sent a signature, it
+might be worth enabling the workaround for this bug to see if it
+helps.
+
+If this bug is detected, PuTTY will sign data in the way OpenSSH
+expects. If this bug is enabled when talking to a correct server,
+SSH2 public-key authentication will fail.
+
+This is an SSH2-specific bug.
+
 \H{config-file} Storing configuration in a file
 
 PuTTY does not currently support storing its configuration in a file