From 2a65c8ef8cb62706a2298f573377ba98fd3a3469 Mon Sep 17 00:00:00 2001 From: Jacob Nevins Date: Mon, 5 Apr 2021 14:30:39 +0100 Subject: [PATCH] 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.) --- doc/config.but | 316 ++++++++++++++++++++++++------------------------- 1 file changed, 158 insertions(+), 158 deletions(-) diff --git a/doc/config.but b/doc/config.but index 4227e3e4..9b6e43d0 100644 --- a/doc/config.but +++ b/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 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 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 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} PuTTY does not currently support storing its configuration in a file