nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-07-01 19:42:48 -05:00
Code Issues Projects Releases Wiki Activity

docs: rearrange protocols in the config section.

Browse Source 
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:
Jacob Nevins
2021-04-05 14:30:39 +01:00
parent 8edeecdcfd
commit 2a65c8ef8c
1 changed files with 158 additions and 158 deletions
Download Patch File Download Diff File Expand all files Collapse all files

316
doc/config.but
View File

@ -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