nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-03-22 14:39:24 -05:00
Code Issues Projects Releases Wiki Activity

Rearrange SSH bug docs to match the GUI.

Browse Source 
No change to the text.
This commit is contained in:
Jacob Nevins 2014-11-08 18:31:15 +00:00
parent 1f45273655
commit 1b4de84e4f
1 changed files with 23 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
doc/config.but
View File

@ -3214,6 +3214,29 @@ ignore messages. If this bug is enabled when talking to a correct
server, the session will succeed, but keepalives will not work and server, the session will succeed, but keepalives will not work and
the session might be less cryptographically secure than it could be. the session might be less cryptographically secure than it could be.
\S{config-ssh-bug-winadj} \q{Chokes on PuTTY's SSH-2 \cq{winadj} requests}
\cfg{winhelp-topic}{ssh.bugs.winadj}
PuTTY sometimes sends a special request to SSH servers in the middle
of channel data, with the name \cw{winadj@putty.projects.tartarus.org}
(see \k{sshnames-channel}). The purpose of this request is to measure
the round-trip time to the server, which PuTTY uses to tune its flow
control. The server does not actually have to \e{understand} the
message; it is expected to send back a \cw{SSH_MSG_CHANNEL_FAILURE}
message indicating that it didn't understand it. (All PuTTY needs for
its timing calculations is \e{some} kind of response.)
It has been known for some SSH servers to get confused by this message
in one way or another \dash because it has a long name, or because
they can't cope with unrecognised request names even to the extent of
sending back the correct failure response, or because they handle it
sensibly but fill up the server's log file with pointless spam, or
whatever. PuTTY therefore supports this bug-compatibility flag: if it
believes the server has this bug, it will never send its
\cq{winadj@putty.projects.tartarus.org} request, and will make do
without its timing data.
\S{config-ssh-bug-hmac2} \q{Miscomputes SSH-2 HMAC keys} \S{config-ssh-bug-hmac2} \q{Miscomputes SSH-2 HMAC keys}
\cfg{winhelp-topic}{ssh.bugs.hmac2} \cfg{winhelp-topic}{ssh.bugs.hmac2}
@ -3320,29 +3343,6 @@ send an over-sized packet. If this bug is enabled when talking to a
correct server, the session will work correctly, but download correct server, the session will work correctly, but download
performance will be less than it could be. performance will be less than it could be.
\S{config-ssh-bug-winadj} \q{Chokes on PuTTY's SSH-2 \cq{winadj} requests}
\cfg{winhelp-topic}{ssh.bugs.winadj}
PuTTY sometimes sends a special request to SSH servers in the middle
of channel data, with the name \cw{winadj@putty.projects.tartarus.org}
(see \k{sshnames-channel}). The purpose of this request is to measure
the round-trip time to the server, which PuTTY uses to tune its flow
control. The server does not actually have to \e{understand} the
message; it is expected to send back a \cw{SSH_MSG_CHANNEL_FAILURE}
message indicating that it didn't understand it. (All PuTTY needs for
its timing calculations is \e{some} kind of response.)
It has been known for some SSH servers to get confused by this message
in one way or another \dash because it has a long name, or because
they can't cope with unrecognised request names even to the extent of
sending back the correct failure response, or because they handle it
sensibly but fill up the server's log file with pointless spam, or
whatever. PuTTY therefore supports this bug-compatibility flag: if it
believes the server has this bug, it will never send its
\cq{winadj@putty.projects.tartarus.org} request, and will make do
without its timing data.
\S{config-ssh-bug-chanreq} \q{Replies to requests on closed channels} \S{config-ssh-bug-chanreq} \q{Replies to requests on closed channels}
\cfg{winhelp-topic}{ssh.bugs.chanreq} \cfg{winhelp-topic}{ssh.bugs.chanreq}