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}
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}
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
~mdw / sgt / putty / blobdiff