\q{\i{Default Settings}} entry in the saved sessions list, with a single
click. Then press the \q{Save} button.
-\lcont{
-Note that PuTTY does not allow you to save a host name into the
-Default Settings entry. This ensures that when PuTTY is started up,
-the host name box is always empty, so a user can always just type in
-a host name and connect.
-}
-
If there is a specific host you want to store the details of how to
connect to, you should create a saved session, which will be
separate from the Default Settings.
\c Second line
\c Third line
+\S{config-lfcr} \q{Implicit LF in every CR}
+
+\cfg{winhelp-topic}{terminal.crhaslf}
+
+Most servers send two control characters, \i{CR} and \i{LF}, to start a
+\i{new line} of the screen. The CR character makes the cursor return to the
+left-hand side of the screen. The LF character makes the cursor move
+one line down (and might make the screen scroll).
+
+Some servers only send CR, and so the newly
+written line is overwritten by the following line. This option causes
+a line feed so that all lines are displayed.
+
\S{config-erase} \q{Use \i{background colour} to erase screen}
\cfg{winhelp-topic}{terminal.bce}
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, \I{BitchX} (an
+commands unexpectedly or inconveniently. In particular, \i{BitchX} (an
IRC client) seems to have a habit of reconfiguring the character set
to something other than the user intended.
\cfg{winhelp-topic}{window.size}
-The \q{\ii{Rows}} and \q{\ii{Columns}} boxes let you set the PuTTY
+The \q{\ii{Columns}} and \q{\ii{Rows}} boxes let you set the PuTTY
window to a precise size. Of course you can also \I{window resizing}drag
the window to a new size while a session is running.
During an interactive session, PuTTY receives a stream of 8-bit
bytes from the server, and in order to display them on the screen it
-needs to know what character set to interpret them in.
-
-There are a lot of character sets to choose from. The \q{Received
-data assumed to be in which character set} option lets you select
-one. By default PuTTY will attempt to choose a character set that is
-right for your \i{locale} as reported by Windows; if it gets it wrong,
-you can select a different one using this control.
+needs to know what character set to interpret them in. Similarly,
+PuTTY needs to know how to translate your keystrokes into the encoding
+the server expects. Unfortunately, there is no satisfactory
+mechanism for PuTTY and the server to communicate this information,
+so it must usually be manually configured.
+
+There are a lot of character sets to choose from. The \q{Remote
+character set} option lets you select one. By default PuTTY will
+attempt to choose a character set that is right for your \i{locale} as
+reported by Windows; if it gets it wrong, you can select a different
+one using this control.
A few notable character sets are:
line-drawing characters, you can select \q{\i{CP437}}.
\b PuTTY also supports \i{Unicode} mode, in which the data coming from
-the server is interpreted as being in the \i{UTF-8} encoding of Unicode.
-If you select \q{UTF-8} as a character set you can use this mode.
-Not all server-side applications will support it.
+the server is interpreted as being in the \i{UTF-8} encoding of Unicode,
+and keystrokes are sent UTF-8 encoded. 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 \i{code page} which is not listed in
the drop-down list, such as code page 866, then you can try entering
\cfg{winhelp-topic}{connection.ipversion}
This option allows the user to select between the old and new
-Internet protocols and addressing schemes (\i{IPv4} and \i{IPv6}). The
-default setting is \q{Auto}, which means PuTTY will do something
+Internet protocols and addressing schemes (\i{IPv4} and \i{IPv6}).
+The selected protocol will be used for most outgoing network
+connections (including connections to \I{proxy}proxies); however,
+tunnels have their own configuration, for which see
+\k{config-ssh-portfwd-address-family}.
+
+The default setting is \q{Auto}, which means PuTTY will do something
sensible and try to guess which protocol you wanted. (If you specify
a literal \i{Internet address}, it will use whichever protocol that
address implies. If you provide a \i{hostname}, it will see what kinds
If you need to force PuTTY to use a particular protocol, you can
explicitly set this to \q{IPv4} or \q{IPv6}.
+\S{config-loghost} \I{logical host name}\q{Logical name of remote host}
+
+\cfg{winhelp-topic}{connection.loghost}
+
+This allows you to tell PuTTY that the host it will really end up
+connecting to is different from where it thinks it is making a
+network connection.
+
+You might use this, for instance, if you had set up an SSH port
+forwarding in one PuTTY session so that connections to some
+arbitrary port (say, \cw{localhost} port 10022) were forwarded to a
+second machine's SSH port (say, \cw{foovax} port 22), and then
+started a second PuTTY connecting to the forwarded port.
+
+In normal usage, the second PuTTY will access the host key cache
+under the host name and port it actually connected to (i.e.
+\cw{localhost} port 10022 in this example). Using the logical host
+name option, however, you can configure the second PuTTY to cache
+the host key under the name of the host \e{you} know that it's
+\e{really} going to end up talking to (here \c{foovax}).
+
+This can be useful if you expect to connect to the same actual
+server through many different channels (perhaps because your port
+forwarding arrangements keep changing): by consistently setting the
+logical host name, you can arrange that PuTTY will not keep asking
+you to reconfirm its host key. Conversely, if you expect to use the
+same local port number for port forwardings to lots of different
+servers, you probably didn't want any particular server's host key
+cached under that local port number.
+
+If you just enter a host name for this option, PuTTY will cache the
+SSH host key under the default SSH port for that host, irrespective
+of the port you really connected to (since the typical scenario is
+like the above example: you connect to a silly real port number and
+your connection ends up forwarded to the normal port-22 SSH server
+of some other machine). To override this, you can append a port
+number to the logical host name, separated by a colon. E.g. entering
+\cq{foovax:2200} as the logical host name will cause the host key to
+be cached as if you had connected to port 2200 of \c{foovax}.
+
+If you provide a host name using this option, it is also displayed
+in other locations which contain the remote host name, such as the
+default window title and the default SSH password prompt. This
+reflects the fact that this is the host you're \e{really} connecting
+to, which is more important than the mere means you happen to be
+using to contact that host. (This applies even if you're using a
+protocol other than SSH.)
+
\H{config-data} The Data panel
The Data panel allows you to configure various pieces of data which
In this box you can type that user name.
+\S{config-username-from-env} \q{Use of system username}
+
+\cfg{winhelp-topic}{connection.usernamefromenv}
+
+When the previous box (\k{config-username}) is left blank, by default,
+PuTTY will prompt for a username at the time you make a connection.
+
+In some environments, such as large corporate networks with \i{single
+sign-on}, a more sensible default may be to use the name of the user
+logged in to the local operating system (if any). This control allows
+you to change the default behaviour.
+
+The current system username is displayed in the dialog as a
+convenience. It is not saved in the configuration; if a saved session
+is later used by a different user, that user's name will be used.
+
\S{config-termtype} \q{\ii{Terminal-type} string}
\cfg{winhelp-topic}{connection.termtype}
session, and also any extra connections made as a result of SSH \i{port
forwarding} (see \k{using-port-forwarding}).
+Note that unlike some software (such as web browsers), PuTTY does not
+attempt to automatically determine whether to use a proxy and (if so)
+which one to use for a given destination. If you need to use a proxy,
+it must always be explicitly configured.
+
\S{config-proxy-type} Setting the proxy type
\cfg{winhelp-topic}{proxy.type}
invent new ones over time, without any changes required to PuTTY's
configuration. We recommend use of this method, if possible.
+In addition, PuTTY supports \i{RSA key exchange}, which requires much less
+computational effort on the part of the client, and somewhat less on
+the part of the server, than Diffie-Hellman key exchange.
+
If the first algorithm PuTTY finds is below the \q{warn below here}
line, you will see a warning box when you make the connection, similar
to that for cipher selection (see \k{config-ssh-encryption}).
authentication available in SSH protocol version 1 only. You might use
them if you were using \i{S/Key} \i{one-time passwords}, for example,
or if you had a physical \i{security token} that generated responses
-to authentication challenges.
+to authentication challenges. They can even be used to prompt for
+simple passwords.
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
+presented with a challenge string (which may 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
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-xauthority} X authority file for local display
+
+\cfg{winhelp-topic}{ssh.tunnels.xauthority}
+
+If you are using X11 forwarding, the local X server to which your
+forwarded connections are eventually directed may itself require
+authorisation.
+
+Some Windows X servers do not require this: they do authorisation by
+simpler means, such as accepting any connection from the local
+machine but not from anywhere else. However, if your X server does
+require authorisation, then PuTTY needs to know what authorisation
+is required.
+
+One way in which this data might be made available is for the X
+server to store it somewhere in a file which has the same format
+as the Unix \c{.Xauthority} file. If this is how your Windows X
+server works, then you can tell PuTTY where to find this file by
+configuring this option. By default, PuTTY will not attempt to find
+any authorisation for your local display.
+
\H{config-ssh-portfwd} \I{port forwarding}The Tunnels panel
\cfg{winhelp-topic}{ssh.tunnels.portfwd}
such as \q{Local ports accept connections from other hosts} only take
effect on new forwardings.
+If the connection you are forwarding over SSH is itself a second SSH
+connection made by another copy of PuTTY, you might find the
+\q{logical host name} configuration option useful to warn PuTTY of
+which host key it should be expecting. See \k{config-loghost} for
+details of this.
+
\S{config-ssh-portfwd-localhost} Controlling the visibility of
forwarded ports
\b for a remote-to-local port forwarding, PuTTY will choose a
sensible protocol for the outgoing connection.
+This overrides the general Internet protocol version preference
+on the Connection panel (see \k{config-address-family}).
+
Note that some operating systems may listen for incoming connections
in IPv4 even if you specifically asked for IPv6, because their IPv4
and IPv6 protocol stacks are linked together. Apparently \i{Linux} does
but keepalives will not work and the session might be more
vulnerable to eavesdroppers than it could be.
-This is an SSH-1-specific bug. No known SSH-2 server fails to deal
-with SSH-2 ignore messages.
-
\S{config-ssh-bug-plainpw1} \q{Refuses all SSH-1 \i{password camouflage}}
\cfg{winhelp-topic}{ssh.bugs.plainpw1}
This is an SSH-1-specific bug.
+\S{config-ssh-bug-ignore2} \q{Chokes on SSH-2 \i{ignore message}s}
+
+\cfg{winhelp-topic}{ssh.bugs.ignore2}
+
+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 in SSH-2
+to confuse the encrypted data stream and make it harder to
+cryptanalyse. It also uses ignore messages for connection
+\i{keepalives} (see \k{config-keepalive}).
+
+If it believes the server to have this bug, PuTTY will stop using
+ignore messages. 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 less cryptographically secure than it could be.
+
\S{config-ssh-bug-hmac2} \q{Miscomputes SSH-2 HMAC keys}
\cfg{winhelp-topic}{ssh.bugs.hmac2}
This is an SSH-2-specific bug.
+\S{config-ssh-bug-maxpkt2} \q{Ignores SSH-2 \i{maximum packet size}}
+
+\cfg{winhelp-topic}{ssh.bugs.maxpkt2}
+
+When an SSH-2 channel is set up, each end announces the maximum size
+of data packet that it is willing to receive for that channel. Some
+servers ignore PuTTY's announcement and send packets larger than PuTTY
+is willing to accept, causing it to report \q{Incoming packet was
+garbled on decryption}.
+
+If this bug is detected, PuTTY never allows the channel's
+\i{flow-control window} to grow large enough to allow the server to
+send an over-sized packet. If this bug is enabled when talking to a
+correct server, the session will work correctly, but download
+performance will be less than it could be.
+
\H{config-serial} The Serial panel
The \i{Serial} panel allows you to configure options that only apply
serial line you want PuTTY to talk to, if your computer has more
than one serial port.
-On Windows, the first serial line is called \cw{COM1}, and if there
+On Windows, the first serial line is called \i\cw{COM1}, and if there
is a second it is called \cw{COM2}, and so on.
This configuration setting is also visible on the Session panel,
projects / u / mdw / putty / blobdiff