mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-07-01 11:32:48 -05:00
docs: rearrange protocols in the config section.
This makes their order match the configuration GUI, as of 18d273fcf1
.
(No change to document content in this commit, just rearrangement.)
This commit is contained in:
316
doc/config.but
316
doc/config.but
@ -2102,164 +2102,6 @@ session is deemed to have started (in a protocol-dependent way), which
|
|||||||
is when they're most likely to be interesting; any further proxy-related
|
is when they're most likely to be interesting; any further proxy-related
|
||||||
messages during the session will only go to the Event Log.
|
messages during the session will only go to the Event Log.
|
||||||
|
|
||||||
\H{config-telnet} The \i{Telnet} panel
|
|
||||||
|
|
||||||
The Telnet panel allows you to configure options that only apply to
|
|
||||||
Telnet sessions.
|
|
||||||
|
|
||||||
\S{config-oldenviron} \q{Handling of OLD_ENVIRON ambiguity}
|
|
||||||
|
|
||||||
The original Telnet mechanism for passing \i{environment variables} was
|
|
||||||
badly specified. At the time the standard (RFC 1408) was written,
|
|
||||||
BSD telnet implementations were already supporting the feature, and
|
|
||||||
the intention of the standard was to describe the behaviour the BSD
|
|
||||||
implementations were already using.
|
|
||||||
|
|
||||||
Sadly there was a typing error in the standard when it was issued,
|
|
||||||
and two vital function codes were specified the wrong way round. BSD
|
|
||||||
implementations did not change, and the standard was not corrected.
|
|
||||||
Therefore, it's possible you might find either \i{BSD} or \i{RFC}-compliant
|
|
||||||
implementations out there. This switch allows you to choose which
|
|
||||||
one PuTTY claims to be.
|
|
||||||
|
|
||||||
The problem was solved by issuing a second standard, defining a new
|
|
||||||
Telnet mechanism called \i\cw{NEW_ENVIRON}, which behaved exactly like
|
|
||||||
the original \i\cw{OLD_ENVIRON} but was not encumbered by existing
|
|
||||||
implementations. Most Telnet servers now support this, and it's
|
|
||||||
unambiguous. This feature should only be needed if you have trouble
|
|
||||||
passing environment variables to quite an old server.
|
|
||||||
|
|
||||||
\S{config-ptelnet} Passive and active \i{Telnet negotiation} modes
|
|
||||||
|
|
||||||
In a Telnet connection, there are two types of data passed between
|
|
||||||
the client and the server: actual text, and \e{negotiations} about
|
|
||||||
which Telnet extra features to use.
|
|
||||||
|
|
||||||
PuTTY can use two different strategies for negotiation:
|
|
||||||
|
|
||||||
\b In \I{active Telnet negotiation}\e{active} mode, PuTTY starts to send
|
|
||||||
negotiations as soon as the connection is opened.
|
|
||||||
|
|
||||||
\b In \I{passive Telnet negotiation}\e{passive} mode, PuTTY will wait to
|
|
||||||
negotiate until it sees a negotiation from the server.
|
|
||||||
|
|
||||||
The obvious disadvantage of passive mode is that if the server is
|
|
||||||
also operating in a passive mode, then negotiation will never begin
|
|
||||||
at all. For this reason PuTTY defaults to active mode.
|
|
||||||
|
|
||||||
However, sometimes passive mode is required in order to successfully
|
|
||||||
get through certain types of firewall and \i{Telnet proxy} server. If
|
|
||||||
you have confusing trouble with a \i{firewall}, you could try enabling
|
|
||||||
passive mode to see if it helps.
|
|
||||||
|
|
||||||
\S{config-telnetkey} \q{Keyboard sends \i{Telnet special commands}}
|
|
||||||
|
|
||||||
If this box is checked, several key sequences will have their normal
|
|
||||||
actions modified:
|
|
||||||
|
|
||||||
\b the Backspace key on the keyboard will send the \I{Erase Character,
|
|
||||||
Telnet special command}Telnet special backspace code;
|
|
||||||
|
|
||||||
\b Control-C will send the Telnet special \I{Interrupt Process, Telnet
|
|
||||||
special command}Interrupt Process code;
|
|
||||||
|
|
||||||
\b Control-Z will send the Telnet special \I{Suspend Process, Telnet
|
|
||||||
special command}Suspend Process code.
|
|
||||||
|
|
||||||
You probably shouldn't enable this
|
|
||||||
unless you know what you're doing.
|
|
||||||
|
|
||||||
\S{config-telnetnl} \q{Return key sends \i{Telnet New Line} instead of ^M}
|
|
||||||
|
|
||||||
Unlike most other remote login protocols, the Telnet protocol has a
|
|
||||||
special \q{\i{new line}} code that is not the same as the usual line
|
|
||||||
endings of Control-M or Control-J. By default, PuTTY sends the
|
|
||||||
Telnet New Line code when you press Return, instead of sending
|
|
||||||
Control-M as it does in most other protocols.
|
|
||||||
|
|
||||||
Most Unix-style Telnet servers don't mind whether they receive
|
|
||||||
Telnet New Line or Control-M; some servers do expect New Line, and
|
|
||||||
some servers prefer to see ^M. If you are seeing surprising
|
|
||||||
behaviour when you press Return in a Telnet session, you might try
|
|
||||||
turning this option off to see if it helps.
|
|
||||||
|
|
||||||
\H{config-rlogin} The Rlogin panel
|
|
||||||
|
|
||||||
The \i{Rlogin} panel allows you to configure options that only apply to
|
|
||||||
Rlogin sessions.
|
|
||||||
|
|
||||||
\S{config-rlogin-localuser} \I{local username in Rlogin}\q{Local username}
|
|
||||||
|
|
||||||
Rlogin allows an automated (password-free) form of login by means of
|
|
||||||
a file called \i\c{.rhosts} on the server. You put a line in your
|
|
||||||
\c{.rhosts} file saying something like \c{jbloggs@pc1.example.com},
|
|
||||||
and then when you make an Rlogin connection the client transmits the
|
|
||||||
username of the user running the Rlogin client. The server checks
|
|
||||||
the username and hostname against \c{.rhosts}, and if they match it
|
|
||||||
\I{passwordless login}does not ask for a password.
|
|
||||||
|
|
||||||
This only works because Unix systems contain a safeguard to stop a
|
|
||||||
user from pretending to be another user in an Rlogin connection.
|
|
||||||
Rlogin connections have to come from \I{privileged port}port numbers below
|
|
||||||
1024, and Unix systems prohibit this to unprivileged processes; so when the
|
|
||||||
server sees a connection from a low-numbered port, it assumes the
|
|
||||||
client end of the connection is held by a privileged (and therefore
|
|
||||||
trusted) process, so it believes the claim of who the user is.
|
|
||||||
|
|
||||||
Windows does not have this restriction: \e{any} user can initiate an
|
|
||||||
outgoing connection from a low-numbered port. Hence, the Rlogin
|
|
||||||
\c{.rhosts} mechanism is completely useless for securely
|
|
||||||
distinguishing several different users on a Windows machine. If you
|
|
||||||
have a \c{.rhosts} entry pointing at a Windows PC, you should assume
|
|
||||||
that \e{anyone} using that PC can \i{spoof} your username in
|
|
||||||
an Rlogin connection and access your account on the server.
|
|
||||||
|
|
||||||
The \q{Local username} control allows you to specify what user name
|
|
||||||
PuTTY should claim you have, in case it doesn't match your \i{Windows
|
|
||||||
user name} (or in case you didn't bother to set up a Windows user
|
|
||||||
name).
|
|
||||||
|
|
||||||
\H{config-supdup} The \i{SUPDUP} panel
|
|
||||||
|
|
||||||
The SUPDUP panel allows you to configure options that only apply
|
|
||||||
to SUPDUP sessions. See \k{using-supdup} for more about the SUPDUP
|
|
||||||
protocol.
|
|
||||||
|
|
||||||
\S{supdup-location} \q{Location string}
|
|
||||||
|
|
||||||
In SUPDUP, the client sends a piece of text of its choice to the
|
|
||||||
server giving the user's location. This is typically displayed in
|
|
||||||
lists of logged-in users.
|
|
||||||
|
|
||||||
By default, PuTTY just defaults this to "The Internet". If you want
|
|
||||||
your location to show up as something more specific, you can configure
|
|
||||||
it here.
|
|
||||||
|
|
||||||
\S{supdup-ascii} \q{Extended ASCII Character set}
|
|
||||||
|
|
||||||
This declares what kind of character set extension your terminal
|
|
||||||
supports. If the server supports it, it will send text using that
|
|
||||||
character set. \q{None} means the standard 95 printable ASCII
|
|
||||||
characters. \q{ITS} means ASCII extended with printable characters in
|
|
||||||
the control character range. This character set is documented in the
|
|
||||||
SUPDUP protocol definition. \q{WAITS} is similar to \q{ITS} but uses
|
|
||||||
some alternative characters in the extended set: most prominently, it
|
|
||||||
will display arrows instead of \c{^} and \c{_}, and \c{\}} instead of
|
|
||||||
\c{~}. \q{ITS} extended ASCII is used by ITS and Lisp machines,
|
|
||||||
whilst \q{WAITS} is only used by the WAITS operating system from the
|
|
||||||
Stanford AI Laboratory.
|
|
||||||
|
|
||||||
\S{supdup-more} \q{**MORE** processing}
|
|
||||||
|
|
||||||
When **MORE** processing is enabled, the server causes output to pause
|
|
||||||
at the bottom of the screen, until a space is typed.
|
|
||||||
|
|
||||||
\S{supdup-scroll} \q{Terminal scrolling}
|
|
||||||
|
|
||||||
This controls whether the terminal will perform scrolling then the
|
|
||||||
cursor goes below the last line, or if the cursor will return to the
|
|
||||||
first line.
|
|
||||||
|
|
||||||
\H{config-ssh} The SSH panel
|
\H{config-ssh} The SSH panel
|
||||||
|
|
||||||
The \i{SSH} panel allows you to configure options that only apply to
|
The \i{SSH} panel allows you to configure options that only apply to
|
||||||
@ -3619,6 +3461,164 @@ the serial line.
|
|||||||
\b \q{DSR/DTR}: flow control is done using the DSR and DTR wires on
|
\b \q{DSR/DTR}: flow control is done using the DSR and DTR wires on
|
||||||
the serial line.
|
the serial line.
|
||||||
|
|
||||||
|
\H{config-telnet} The \i{Telnet} panel
|
||||||
|
|
||||||
|
The Telnet panel allows you to configure options that only apply to
|
||||||
|
Telnet sessions.
|
||||||
|
|
||||||
|
\S{config-oldenviron} \q{Handling of OLD_ENVIRON ambiguity}
|
||||||
|
|
||||||
|
The original Telnet mechanism for passing \i{environment variables} was
|
||||||
|
badly specified. At the time the standard (RFC 1408) was written,
|
||||||
|
BSD telnet implementations were already supporting the feature, and
|
||||||
|
the intention of the standard was to describe the behaviour the BSD
|
||||||
|
implementations were already using.
|
||||||
|
|
||||||
|
Sadly there was a typing error in the standard when it was issued,
|
||||||
|
and two vital function codes were specified the wrong way round. BSD
|
||||||
|
implementations did not change, and the standard was not corrected.
|
||||||
|
Therefore, it's possible you might find either \i{BSD} or \i{RFC}-compliant
|
||||||
|
implementations out there. This switch allows you to choose which
|
||||||
|
one PuTTY claims to be.
|
||||||
|
|
||||||
|
The problem was solved by issuing a second standard, defining a new
|
||||||
|
Telnet mechanism called \i\cw{NEW_ENVIRON}, which behaved exactly like
|
||||||
|
the original \i\cw{OLD_ENVIRON} but was not encumbered by existing
|
||||||
|
implementations. Most Telnet servers now support this, and it's
|
||||||
|
unambiguous. This feature should only be needed if you have trouble
|
||||||
|
passing environment variables to quite an old server.
|
||||||
|
|
||||||
|
\S{config-ptelnet} Passive and active \i{Telnet negotiation} modes
|
||||||
|
|
||||||
|
In a Telnet connection, there are two types of data passed between
|
||||||
|
the client and the server: actual text, and \e{negotiations} about
|
||||||
|
which Telnet extra features to use.
|
||||||
|
|
||||||
|
PuTTY can use two different strategies for negotiation:
|
||||||
|
|
||||||
|
\b In \I{active Telnet negotiation}\e{active} mode, PuTTY starts to send
|
||||||
|
negotiations as soon as the connection is opened.
|
||||||
|
|
||||||
|
\b In \I{passive Telnet negotiation}\e{passive} mode, PuTTY will wait to
|
||||||
|
negotiate until it sees a negotiation from the server.
|
||||||
|
|
||||||
|
The obvious disadvantage of passive mode is that if the server is
|
||||||
|
also operating in a passive mode, then negotiation will never begin
|
||||||
|
at all. For this reason PuTTY defaults to active mode.
|
||||||
|
|
||||||
|
However, sometimes passive mode is required in order to successfully
|
||||||
|
get through certain types of firewall and \i{Telnet proxy} server. If
|
||||||
|
you have confusing trouble with a \i{firewall}, you could try enabling
|
||||||
|
passive mode to see if it helps.
|
||||||
|
|
||||||
|
\S{config-telnetkey} \q{Keyboard sends \i{Telnet special commands}}
|
||||||
|
|
||||||
|
If this box is checked, several key sequences will have their normal
|
||||||
|
actions modified:
|
||||||
|
|
||||||
|
\b the Backspace key on the keyboard will send the \I{Erase Character,
|
||||||
|
Telnet special command}Telnet special backspace code;
|
||||||
|
|
||||||
|
\b Control-C will send the Telnet special \I{Interrupt Process, Telnet
|
||||||
|
special command}Interrupt Process code;
|
||||||
|
|
||||||
|
\b Control-Z will send the Telnet special \I{Suspend Process, Telnet
|
||||||
|
special command}Suspend Process code.
|
||||||
|
|
||||||
|
You probably shouldn't enable this
|
||||||
|
unless you know what you're doing.
|
||||||
|
|
||||||
|
\S{config-telnetnl} \q{Return key sends \i{Telnet New Line} instead of ^M}
|
||||||
|
|
||||||
|
Unlike most other remote login protocols, the Telnet protocol has a
|
||||||
|
special \q{\i{new line}} code that is not the same as the usual line
|
||||||
|
endings of Control-M or Control-J. By default, PuTTY sends the
|
||||||
|
Telnet New Line code when you press Return, instead of sending
|
||||||
|
Control-M as it does in most other protocols.
|
||||||
|
|
||||||
|
Most Unix-style Telnet servers don't mind whether they receive
|
||||||
|
Telnet New Line or Control-M; some servers do expect New Line, and
|
||||||
|
some servers prefer to see ^M. If you are seeing surprising
|
||||||
|
behaviour when you press Return in a Telnet session, you might try
|
||||||
|
turning this option off to see if it helps.
|
||||||
|
|
||||||
|
\H{config-rlogin} The Rlogin panel
|
||||||
|
|
||||||
|
The \i{Rlogin} panel allows you to configure options that only apply to
|
||||||
|
Rlogin sessions.
|
||||||
|
|
||||||
|
\S{config-rlogin-localuser} \I{local username in Rlogin}\q{Local username}
|
||||||
|
|
||||||
|
Rlogin allows an automated (password-free) form of login by means of
|
||||||
|
a file called \i\c{.rhosts} on the server. You put a line in your
|
||||||
|
\c{.rhosts} file saying something like \c{jbloggs@pc1.example.com},
|
||||||
|
and then when you make an Rlogin connection the client transmits the
|
||||||
|
username of the user running the Rlogin client. The server checks
|
||||||
|
the username and hostname against \c{.rhosts}, and if they match it
|
||||||
|
\I{passwordless login}does not ask for a password.
|
||||||
|
|
||||||
|
This only works because Unix systems contain a safeguard to stop a
|
||||||
|
user from pretending to be another user in an Rlogin connection.
|
||||||
|
Rlogin connections have to come from \I{privileged port}port numbers below
|
||||||
|
1024, and Unix systems prohibit this to unprivileged processes; so when the
|
||||||
|
server sees a connection from a low-numbered port, it assumes the
|
||||||
|
client end of the connection is held by a privileged (and therefore
|
||||||
|
trusted) process, so it believes the claim of who the user is.
|
||||||
|
|
||||||
|
Windows does not have this restriction: \e{any} user can initiate an
|
||||||
|
outgoing connection from a low-numbered port. Hence, the Rlogin
|
||||||
|
\c{.rhosts} mechanism is completely useless for securely
|
||||||
|
distinguishing several different users on a Windows machine. If you
|
||||||
|
have a \c{.rhosts} entry pointing at a Windows PC, you should assume
|
||||||
|
that \e{anyone} using that PC can \i{spoof} your username in
|
||||||
|
an Rlogin connection and access your account on the server.
|
||||||
|
|
||||||
|
The \q{Local username} control allows you to specify what user name
|
||||||
|
PuTTY should claim you have, in case it doesn't match your \i{Windows
|
||||||
|
user name} (or in case you didn't bother to set up a Windows user
|
||||||
|
name).
|
||||||
|
|
||||||
|
\H{config-supdup} The \i{SUPDUP} panel
|
||||||
|
|
||||||
|
The SUPDUP panel allows you to configure options that only apply
|
||||||
|
to SUPDUP sessions. See \k{using-supdup} for more about the SUPDUP
|
||||||
|
protocol.
|
||||||
|
|
||||||
|
\S{supdup-location} \q{Location string}
|
||||||
|
|
||||||
|
In SUPDUP, the client sends a piece of text of its choice to the
|
||||||
|
server giving the user's location. This is typically displayed in
|
||||||
|
lists of logged-in users.
|
||||||
|
|
||||||
|
By default, PuTTY just defaults this to "The Internet". If you want
|
||||||
|
your location to show up as something more specific, you can configure
|
||||||
|
it here.
|
||||||
|
|
||||||
|
\S{supdup-ascii} \q{Extended ASCII Character set}
|
||||||
|
|
||||||
|
This declares what kind of character set extension your terminal
|
||||||
|
supports. If the server supports it, it will send text using that
|
||||||
|
character set. \q{None} means the standard 95 printable ASCII
|
||||||
|
characters. \q{ITS} means ASCII extended with printable characters in
|
||||||
|
the control character range. This character set is documented in the
|
||||||
|
SUPDUP protocol definition. \q{WAITS} is similar to \q{ITS} but uses
|
||||||
|
some alternative characters in the extended set: most prominently, it
|
||||||
|
will display arrows instead of \c{^} and \c{_}, and \c{\}} instead of
|
||||||
|
\c{~}. \q{ITS} extended ASCII is used by ITS and Lisp machines,
|
||||||
|
whilst \q{WAITS} is only used by the WAITS operating system from the
|
||||||
|
Stanford AI Laboratory.
|
||||||
|
|
||||||
|
\S{supdup-more} \q{**MORE** processing}
|
||||||
|
|
||||||
|
When **MORE** processing is enabled, the server causes output to pause
|
||||||
|
at the bottom of the screen, until a space is typed.
|
||||||
|
|
||||||
|
\S{supdup-scroll} \q{Terminal scrolling}
|
||||||
|
|
||||||
|
This controls whether the terminal will perform scrolling then the
|
||||||
|
cursor goes below the last line, or if the cursor will return to the
|
||||||
|
first line.
|
||||||
|
|
||||||
\H{config-file} \ii{Storing configuration in a file}
|
\H{config-file} \ii{Storing configuration in a file}
|
||||||
|
|
||||||
PuTTY does not currently support storing its configuration in a file
|
PuTTY does not currently support storing its configuration in a file
|
||||||
|
Reference in New Issue
Block a user