X-Git-Url: https://git.distorted.org.uk/u/mdw/putty/blobdiff_plain/15933a9b9d1cacf8de7ac497928991820b43c361..b3ebaa287b8a57f3d35675889adc86f6384eb458:/doc/config.but diff --git a/doc/config.but b/doc/config.but index 4193681f..71cee3e5 100644 --- a/doc/config.but +++ b/doc/config.but @@ -1,4 +1,4 @@ -\versionid $Id: config.but,v 1.41 2002/09/23 09:55:11 jacob Exp $ +\versionid $Id: config.but,v 1.48 2003/01/12 14:11:38 simon Exp $ \C{config} Configuring PuTTY @@ -686,6 +686,11 @@ constitute an overload, how short a time period they have to arrive 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 @@ -1434,6 +1439,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} @@ -1449,7 +1497,8 @@ proxies and SOCKS 5 proxies. \b SOCKS 4 can use the \q{Username} field, but does not support passwords. -\b Authentication is meaningless in Telnet proxies. +\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 @@ -1467,8 +1516,20 @@ 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. To get a -literal \c{%} sign, enter \c{%%}. +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 @@ -1826,6 +1887,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} @@ -1863,6 +1971,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 @@ -2005,7 +2126,7 @@ server, communication will fail. This is an SSH2-specific bug. -\S{config-ssh-bug-ssh} \q{Requires padding on SSH2 RSA signatures} +\S{config-ssh-bug-sig} \q{Requires padding on SSH2 RSA signatures} \cfg{winhelp-topic}{ssh.bugs.rsapad2} @@ -2024,6 +2145,23 @@ 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 PuTTY does not currently support storing its configuration in a file