\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.
PuTTY sessions, for debugging, analysis or future reference.
The main option is a radio-button set that specifies whether PuTTY
-will log anything at all. The options are
+will log anything at all. The options are:
-\b \q{Logging turned off completely}. This is the default option; in
-this mode PuTTY will not create a log file at all.
+\b \q{None}. This is the default option; in this mode PuTTY will not
+create a log file at all.
-\b \q{Log printable output only}. In this mode, a log file will be
+\b \q{Printable output}. In this mode, a log file will be
created and written to, but only printable text will be saved into
it. The various terminal control codes that are typically sent down
an interactive session alongside the printable text will be omitted.
This might be a useful mode if you want to read a log file in a text
editor and hope to be able to make sense of it.
-\b \q{Log all session output}. In this mode, \e{everything} sent by
+\b \q{All session output}. In this mode, \e{everything} sent by
the server into your terminal session is logged. If you view the log
file in a text editor, therefore, you may well find it full of
strange control characters. This is a particularly useful mode if
else can replay the session later in slow motion and watch to see
what went wrong.
-\b \q{\i{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 can appear in the log file; see
-\k{config-logssh} for options that may help to remove sensitive
-material from the log file before you send it to anyone else.
+\b \I{SSH packet log}\q{SSH packets}. 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 (as well as \i{Event Log}
+entries). 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 can
+appear in the log file; see \k{config-logssh} for options that may
+help to remove sensitive material from the log file before you send it
+to anyone else.
+
+\b \q{SSH packets and raw data}. In this mode, as well as the
+decrypted packets (as in the previous mode), the \e{raw} (encrypted,
+compressed, etc) packets are \e{also} logged. This could be useful to
+diagnose corruption in transit. (The same caveats as the previous mode
+apply, of course.)
+
+Note that the non-SSH logging options (\q{Printable output} and
+\q{All session output}) only work with PuTTY proper; in programs
+without terminal emulation (such as Plink), they will have no effect,
+even if enabled via saved settings.
\S{config-logfilename} \q{Log file name}
\cfg{winhelp-topic}{logging.ssh.omitpassword}
-When checked, password fields are removed from the log of transmitted
-packets. (This includes any user responses to challenge-response
-authentication methods such as \q{keyboard-interactive}.) This does
-not include X11 authentication data if using X11 forwarding.
+When checked, decrypted password fields are removed from the log of
+transmitted packets. (This includes any user responses to
+challenge-response authentication methods such as
+\q{keyboard-interactive}.) This does not include X11 authentication
+data if using X11 forwarding.
Note that this will only omit data that PuTTY \e{knows} to be a
password. However, if you start another login session within your
\cfg{winhelp-topic}{logging.ssh.omitdata}
-When checked, all \q{session data} is omitted; this is defined as data
-in terminal sessions and in forwarded channels (TCP, X11, and
-authentication agent). This will usually substantially reduce the size
-of the resulting log file.
+When checked, all decrypted \q{session data} is omitted; this is
+defined as data in terminal sessions and in forwarded channels (TCP,
+X11, and authentication agent). This will usually substantially reduce
+the size of the resulting log file.
This option is disabled by default.
\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}
unexpectedly or inconveniently, you can tell PuTTY not to respond to
those server commands.
-\S{config-features-qtitle} Disabling remote \i{window title} querying
+\S{config-features-qtitle} Response to remote \i{window title} querying
\cfg{winhelp-topic}{features.qtitle}
typed at the keyboard. This allows an attacker to fake keypresses
and potentially cause your server-side applications to do things you
didn't want. Therefore this feature is disabled by default, and we
-recommend you do not turn it on unless you \e{really} know what you
-are doing.
+recommend you do not set it to \q{Window title} unless you \e{really}
+know what you are doing.
+
+There are three settings for this option:
+
+\dt \q{None}
+
+\dd PuTTY makes no response whatsoever to the relevant escape
+sequence. This may upset server-side software that is expecting some
+sort of response.
+
+\dt \q{Empty string}
+
+\dd PuTTY makes a well-formed response, but leaves it blank. Thus,
+server-side software that expects a response is kept happy, but an
+attacker cannot influence the response string. This is probably the
+setting you want if you have no better ideas.
+
+\dt \q{Window title}
+
+\dd PuTTY responds with the actual window title. This is dangerous for
+the reasons described above.
\S{config-features-dbackspace} Disabling \i{destructive backspace}
\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.
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}
This could be used, for instance, to talk to some kind of network proxy
that PuTTY does not natively support; or you could tunnel a connection
over something other than TCP/IP entirely.
+
+If you want your local proxy command to make a secondary SSH
+connection to a proxy host and then tunnel the primary connection
+over that, you might well want the \c{-nc} command-line option in
+Plink. See \k{using-cmdline-ncmode} for more information.
}
\S{config-proxy-exclude} Excluding parts of the network from proxying
get two warnings similar to the one above, possibly with different
encryptions.
-Single-DES is not recommended in the SSH-2 draft protocol
+Single-DES is not recommended in the SSH-2 protocol
standards, but one or two server implementations do support it.
PuTTY can use single-DES to interoperate with
these servers if you enable the \q{Enable legacy use of single-DES in
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}).
exchange (\q{rekey}). You can also force a key exchange at any time
from the Special Commands menu (see \k{using-specials}).
-\# FIXME: do we have any additions to the SSH-2 drafts' advice on
+\# FIXME: do we have any additions to the SSH-2 specs' advice on
these values? Do we want to enforce any limits?
\b \q{Max minutes before rekey} specifies the amount of time that is
to a remote destination (\q{Local}) or \I{remote port forwarding}forward
a remote port to a local destination (\q{Remote}). Alternatively,
select \q{Dynamic} if you want PuTTY to \I{dynamic port forwarding}provide
-a local SOCKS 4/4A/5 proxy on a local port.
+a local SOCKS 4/4A/5 proxy on a local port (note that this proxy only
+supports TCP connections; the SSH protocol does not support forwarding
+\i{UDP}).
\b Enter a source \i{port number} into the \q{Source port} box. For
local forwardings, PuTTY will listen on this port of your PC. For
known to the local system. For instance, in the \q{Destination} box,
you could enter \c{popserver.example.com:pop3}.
-You can modify the currently active set of port forwardings in
-mid-session using \q{Change Settings} (see \k{using-changesettings}).
-If you delete a local or dynamic port forwarding in mid-session, PuTTY
-will stop listening for connections on that port, so it can be re-used
-by another program. If you delete a remote port forwarding, note that:
+You can \I{port forwarding, changing mid-session}modify the currently
+active set of port forwardings in mid-session using \q{Change
+Settings} (see \k{using-changesettings}). If you delete a local or
+dynamic port forwarding in mid-session, PuTTY will stop listening for
+connections on that port, so it can be re-used by another program. If
+you delete a remote port forwarding, note that:
\b The SSH-1 protocol contains no mechanism for asking the server to
stop listening on a remote port.
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 SSH-1, 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}).
+message whenever it receives it. PuTTY uses ignore messages to
+\I{password camouflage}hide the password packet in SSH-1, so that
+a listener cannot tell the length of the user's password; it also
+uses ignore messages for connection \i{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
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
+If this \q{bug} is detected, PuTTY will assume that neither ignore
+messages nor padding are acceptable, and that it thus has 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.
Versions below 3.3 of \i{OpenSSH} require SSH-2 RSA signatures to be
padded with zero bytes to the same length as the RSA key modulus.
-The SSH-2 draft specification says that an unpadded signature MUST be
+The SSH-2 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.
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