\q{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
saved session name.) Then press the \q{Save} button. Your saved
session name should now appear in the list box.
+\lcont{
+You can also save settings in mid-session, from the \q{Change Settings}
+dialog. Settings changed since the start of the session will be saved
+with their current values; as well as settings changed through the
+dialog, this includes changes in window size, window title changes
+sent by the server, and so on.
+}
+
\b To reload a saved session: single-click to select the session
name in the list box, and then press the \q{Load} button. Your saved
settings should all appear in the configuration panel.
\b To modify a saved session: first load it as described above. Then
make the changes you want. Come back to the Session panel, and press
the \q{Save} button. The new settings will be saved over the top of
-the old ones
+the old ones.
\lcont{
To save the new settings under a different name, you can enter the new
protocols offer no way of implementing them. (For an alternative, see
\k{config-tcp-keepalives}.)
-Note that if you are using SSH1 and the server has a bug that makes
-it unable to deal with SSH1 ignore messages (see
+Note that if you are using SSH-1 and the server has a bug that makes
+it unable to deal with SSH-1 ignore messages (see
\k{config-ssh-bug-ignore1}), enabling keepalives will have no effect.
\S{config-nodelay} \q{Disable Nagle's algorithm}
get a faster response to your keystrokes when connecting to some
types of server.
-The Nagle algorithm is disabled by default.
+The Nagle algorithm is disabled by default for interactive connections.
\S{config-tcp-keepalives} \q{Enable TCP keepalives}
be configured within PuTTY.
\b If the operating system does not receive a response to a keepalive,
-it may send out more in quick succession and if terminate the connection
+it may send out more in quick succession and terminate the connection
if no response is received.
TCP keepalives may be more useful for ensuring that half-open connections
The Data panel allows you to configure various pieces of data which
can be sent to the server to affect your connection at the far end.
-Each options on this panel applies to more than one protocol.
+Each option on this panel applies to more than one protocol.
Options which apply to only one protocol appear on that protocol's
configuration panels.
whole mechanism.
Version 2 of the SSH protocol also provides a similar mechanism,
-which is easier to implement without security flaws. Newer SSH2
+which is easier to implement without security flaws. Newer SSH-2
servers are more likely to support it than older ones.
-This configuration data is not used in the SSHv1, rlogin or raw
+This configuration data is not used in the SSH-1, rlogin or raw
protocols.
To add an environment variable to the list transmitted down the
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 draft 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
-SSH 2} option; by default this is disabled and PuTTY will stick to
+SSH-2} option; by default this is disabled and PuTTY will stick to
recommended ciphers.
\H{config-ssh-kex} The Kex panel
PuTTY will not rekey due to elapsed time. The SSH-2 protocol
specification recommends a timeout of at most 60 minutes.
+You might have a need to disable time-based rekeys completely for the same
+reasons that keepalives aren't always helpful. If you anticipate
+suffering a network dropout of several hours in the middle of an SSH
+connection, but were not actually planning to send \e{data} down
+that connection during those hours, then an attempted rekey in the
+middle of the dropout will probably cause the connection to be
+abandoned, whereas if rekeys are disabled then the connection should
+in principle survive (in the absence of interfering firewalls). See
+\k{config-keepalive} for more discussion of these issues; for these
+purposes, rekeys have much the same properties as keepalives.
+(Except that rekeys have cryptographic value in themselves, so you
+should bear that in mind when deciding whether to turn them off.)
+Note, however, the the SSH \e{server} can still initiate rekeys.
+
\b \q{Max data before rekey} specifies the amount of data (in bytes)
that is permitted to flow in either direction before a rekey is
initiated. If this is set to zero, PuTTY will not rekey due to
}
-PuTTY can be prevented from initiating a rekey entirely by setting
-both of these values to zero. (Note, however, that the SSH
-\e{server} may still initiate rekeys.)
-
-You might have a need to disable rekeys completely for the same
-reasons that keepalives aren't always helpful. If you anticipate
-suffering a network dropout of several hours in the middle of an SSH
-connection, but were not actually planning to send \e{data} down
-that connection during those hours, then an attempted rekey in the
-middle of the dropout will probably cause the connection to be
-abandoned, whereas if rekeys are disabled then the connection should
-in principle survive (in the absence of interfering firewalls). See
-\k{config-keepalive} for more discussion of these issues; for these
-purposes, rekeys have much the same properties as keepalives.
-(Except that rekeys have cryptographic value in themselves, so you
-should bear that in mind when deciding whether to turn them off.)
+Disabling data-based rekeys entirely is a bad idea. The integrity,
+and to a lesser extent, confidentiality of the SSH-2 protocol depend
+in part on rekeys occuring before a 32-bit packet sequence number
+wraps around. Unlike time-based rekeys, data-based rekeys won't occur
+when the SSH connection is idle, so they shouldn't cause the same
+problems. The SSH-1 protocol, incidentally, has even weaker integrity
+protection than SSH-2 without rekeys.
\H{config-ssh-auth} The Auth panel
\cfg{winhelp-topic}{ssh.auth.ki}
-The SSH 2 equivalent of TIS authentication is called
+The SSH-2 equivalent of TIS authentication is called
\q{keyboard-interactive}. It is a flexible authentication method
using an arbitrary sequence of requests and responses; so it is not
only useful for challenge/response mechanisms such as S/Key, but it
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}
+\S{config-ssh-changeuser} \q{Allow attempted changes of username in SSH-2}
\cfg{winhelp-topic}{ssh.auth.changeuser}
-In the SSH 1 protocol, it is impossible to change username after
+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
+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,
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}).
+This key must be in PuTTY's native format (\c{*.PPK}). If you have a
+private key in another format that you want to use with PuTTY, see
+\k{puttygen-conversions}.
\H{config-ssh-x11} The X11 panel
To enable X11 forwarding, check the \q{Enable X11 forwarding} box.
If your X display is somewhere unusual, you will need to enter its
location in the \q{X display location} box; if this is left blank,
-PuTTY try to find a sensible default in the environment, or use the
+PuTTY will try to find a sensible default in the environment, or use the
primary local display (\c{:0}) if that fails.
See \k{using-x-forwarding} for more information about X11
\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
+\b This authentication mechanism will only work in SSH-2. 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.
See \k{using-port-forwarding} for more information on how this
works and its restrictions.
+In place of port numbers, you can enter service names, if they are
+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}. 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:
+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 SSHv1 protocol contains no mechanism for asking the server to
+\b The SSH-1 protocol contains no mechanism for asking the server to
stop listening on a remote port.
-\b The SSHv2 protocol does contain such a mechanism, but not all SSH
+\b The SSH-2 protocol does contain such a mechanism, but not all SSH
servers support it. (In particular, OpenSSH does not support it in
any version earlier than 3.9.)
least be reasonably sure that server-side programs can no longer
access the service at your end of the port forwarding.
+If you delete a forwarding, any existing connections established using
+that forwarding remain open. Similarly, changes to global settings
+such as \q{Local ports accept connections from other hosts} only take
+effect on new forwardings.
+
\S{config-ssh-portfwd-localhost} Controlling the visibility of
forwarded ports
\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).
+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).
\S{config-ssh-portfwd-address-family} Selecting Internet protocol
version for forwarded ports
\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}
+\S{config-ssh-bug-ignore1} \q{Chokes on SSH-1 ignore messages}
\cfg{winhelp-topic}{ssh.bugs.ignore1}
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
+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}).
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
+back to a secondary defence against SSH-1 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.
+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 SSH1 password camouflage}
+\S{config-ssh-bug-plainpw1} \q{Refuses all SSH-1 password camouflage}
\cfg{winhelp-topic}{ssh.bugs.plainpw1}
-When talking to an SSH1 server which cannot deal with ignore
+When talking to an SSH-1 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
+violation of the SSH-1 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
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
+This is an SSH-1-specific bug. SSH-2 is secure against this type of
attack.
-\S{config-ssh-bug-rsa1} \q{Chokes on SSH1 RSA authentication}
+\S{config-ssh-bug-rsa1} \q{Chokes on SSH-1 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
+Some SSH-1 servers cannot deal with RSA authentication messages at
+all. If Pageant is running and contains any SSH-1 keys, PuTTY will
normally automatically try RSA authentication before falling back to
passwords, so these servers will crash when they see the RSA attempt.
server, the session will succeed, but of course RSA authentication
will be impossible.
-This is an SSH1-specific bug.
+This is an SSH-1-specific bug.
-\S{config-ssh-bug-hmac2} \q{Miscomputes SSH2 HMAC keys}
+\S{config-ssh-bug-hmac2} \q{Miscomputes SSH-2 HMAC keys}
\cfg{winhelp-topic}{ssh.bugs.hmac2}
possible. If this bug is enabled when talking to a correct server,
communication will fail.
-This is an SSH2-specific bug.
+This is an SSH-2-specific bug.
-\S{config-ssh-bug-derivekey2} \q{Miscomputes SSH2 encryption keys}
+\S{config-ssh-bug-derivekey2} \q{Miscomputes SSH-2 encryption keys}
\cfg{winhelp-topic}{ssh.bugs.derivekey2}
be possible. If this bug is enabled when talking to a correct
server, communication will fail.
-This is an SSH2-specific bug.
+This is an SSH-2-specific bug.
-\S{config-ssh-bug-sig} \q{Requires padding on SSH2 RSA signatures}
+\S{config-ssh-bug-sig} \q{Requires padding on SSH-2 RSA signatures}
\cfg{winhelp-topic}{ssh.bugs.rsapad2}
-Versions below 3.3 of OpenSSH require SSH2 RSA signatures to be
+Versions below 3.3 of OpenSSH require SSH-2 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
+The SSH-2 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.
servers usually still accept padded signatures because they're used
to talking to OpenSSH.
-This is an SSH2-specific bug.
+This is an SSH-2-specific bug.
\S{config-ssh-bug-pksessid2} \q{Misuses the session ID in PK auth}
\cfg{winhelp-topic}{ssh.bugs.pksessid2}
-Versions below 2.3 of OpenSSH require SSH2 public-key authentication
+Versions below 2.3 of OpenSSH require SSH-2 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
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.
+SSH-2 public-key authentication will fail.
-This is an SSH2-specific bug.
+This is an SSH-2-specific bug.
-\S{config-ssh-bug-rekey} \q{Ignores key re-exchange completely}
+\S{config-ssh-bug-rekey} \q{Handles key re-exchange badly}
\cfg{winhelp-topic}{ssh.bugs.rekey2}
-Some very old SSH servers cannot cope with repeat key exchange at
+Some SSH servers cannot cope with repeat key exchange at
all, and will ignore attempts by the client to start one. Since
PuTTY pauses the session while performing a repeat key exchange, the
effect of this would be to cause the session to hang after an hour
(unless you have your rekey timeout set differently; see
\k{config-ssh-kex-rekey} for more about rekeys).
+Other, very old, SSH servers handle repeat key exchange even more
+badly, and disconnect upon receiving a repeat key exchange request.
If this bug is detected, PuTTY will never initiate a repeat key
exchange. If this bug is enabled when talking to a correct server,
the session should still function, but may be less secure than you
would expect.
-This is an SSH2-specific bug.
+This is an SSH-2-specific bug.
\H{config-file} Storing configuration in a file
projects / u / mdw / putty / blobdiff