Note that this is \e{not} the feature of PuTTY which the server will
typically use to determine your terminal type. That feature is the
-\q{Terminal-type string} in the Connection panel; see
+\q{\ii{Terminal-type} string} in the Connection panel; see
\k{config-termtype} for details.
You can include control characters in the answerback string using
\H{config-keyboard} The Keyboard panel
The Keyboard configuration panel allows you to control the behaviour
-of the \i{keyboard} in PuTTY.
+of the \i{keyboard} in PuTTY. The correct state for many of these
+settings depends on what the server to which PuTTY is connecting
+expects. With a \i{Unix} server, this is likely to depend on the
+\i\c{termcap} or \i\c{terminfo} entry it uses, which in turn is likely to
+be controlled by the \q{\ii{Terminal-type} string} setting in the Connection
+panel; see \k{config-termtype} for details. If none of the settings here
+seems to help, you may find \k{faq-keyboard} to be useful.
\S{config-backspace} Changing the action of the \ii{Backspace key}
side doesn't believe there is an open connection any more.
Keepalives can make this sort of problem worse, because they
increase the probability that PuTTY will attempt to send data during
-a break in connectivity. Therefore, you might find they help
+a break in connectivity. (Other types of periodic network activity
+can cause this behaviour; in particular, SSH-2 re-keys can have
+this effect. See \k{config-ssh-kex-rekey}.)
+
+Therefore, you might find that keepalives help
connection loss, or you might find they make it worse, depending on
what \e{kind} of network problems you have between you and the
server.
send the right \i{control sequence}s to each one, the server will need
to know what type of terminal it is dealing with. Therefore, each of
the SSH, Telnet and Rlogin protocols allow a text string to be sent
-down the connection describing the terminal.
+down the connection describing the terminal. On a \i{Unix} server,
+this selects an entry from the \i\c{termcap} or \i\c{terminfo} database
+that tells applications what \i{control sequences} to send to the
+terminal, and what character sequences to expect the \i{keyboard}
+to generate.
PuTTY attempts to emulate the Unix \i\c{xterm} program, and by default
it reflects this by sending \c{xterm} as a terminal-type string. If
mail user agent, for example). If you want to do this, enter the
command in the \q{\ii{Remote command}} box.
+Note that most servers will close the session after executing the
+command.
+
\S{config-ssh-noshell} \q{Don't start a \I{remote shell}shell or
\I{remote command}command at all}
\b \i{Arcfour} (RC4) - 256 or 128-bit stream cipher (SSH-2 only)
-\b \i{Blowfish} - 128-bit CBC
+\b \i{Blowfish} - 256-bit SDCTR (SSH-2 only) or 128-bit CBC
-\b \ii{Triple-DES} - 168-bit CBC
+\b \ii{Triple-DES} - 168-bit SDCTR (SSH-2 only) or CBC
\b \ii{Single-DES} - 56-bit CBC (see below for SSH-2)
The Auth panel allows you to configure \i{authentication} options for
SSH sessions.
+\S{config-ssh-noauth} \q{Bypass authentication entirely}
+
+\cfg{winhelp-topic}{ssh.auth.bypass}
+
+In SSH-2, it is possible to establish a connection without using SSH's
+mechanisms to identify or authenticate oneself to the server. Some
+servers may prefer to handle authentication in the data channel, for
+instance, or may simply require no authentication whatsoever.
+
+By default, PuTTY assumes the server requires authentication (most
+do), and thus must provide a username. If you find you are getting
+unwanted username prompts, you could try checking this option.
+
+This option only affects SSH-2 connections. SSH-1 connections always
+require an authentication step.
+
\S{config-ssh-tis} \q{Attempt \I{TIS authentication}TIS or
\i{CryptoCard authentication}}
\cfg{winhelp-topic}{ssh.auth.tis}
-TIS and CryptoCard authentication are simple \I{challenge/response
-authentication}challenge/response forms of 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.
+TIS and CryptoCard authentication are (despite their names) generic
+forms of simple \I{challenge/response authentication}challenge/response
+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.
With this switch enabled, PuTTY will attempt these forms of
authentication if the server is willing to try them. You will be
projects / u / mdw / putty / blobdiff