nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-25 01:02:24 +00:00
Code Issues Projects Releases Wiki Activity

Remove some ancient cruft from the FAQ.

Browse Source 
- I haven't heard of OpenSSH/OpenSSL mismatches being a common problem
   for a long time. Specific advice about OpenSSH 3.1/3.4 seems unlikely
   to be useful these days.
 - "Incorrect MAC received on packet" doesn't seem to be a common
   problem these days, and if anyone encounters it, the words in the
   "Errors" bit of the docs seem adequate without a FAQ entry as well.
This commit is contained in:
Jacob Nevins 2017-05-23 23:13:17 +01:00
parent 12bd5a6c72
commit 22cf2823d1
2 changed files with 9 additions and 72 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
doc/errors.but
View File

@ -122,9 +122,7 @@ ridiculous amount of memory, and will terminate with an \q{Out of
memory} error.
This can happen in SSH-2, if PuTTY and the server have not enabled
encryption in the same way (see \k{faq-outofmem} in the FAQ). Some
versions of \i{OpenSSH} have a known problem with this: see
\k{faq-openssh-bad-openssl}.
encryption in the same way (see \k{faq-outofmem} in the FAQ).
This can also happen in PSCP or PSFTP, if your \i{login scripts} on the
server generate output: the client program will be expecting an SFTP
@ -233,8 +231,13 @@ protection (such as HTTP) will manifest in more subtle failures (such
as misdisplayed text or images in a web browser) which may not be
noticed.
A known server problem which can cause this error is described in
\k{faq-openssh-bad-openssl} in the FAQ.
Occasionally this has been caused by server bugs. An example is the
bug described at \k{config-ssh-bug-hmac2}, although you're very
unlikely to encounter that one these days.
In this context MAC stands for \ii{Message Authentication Code}. It's a
cryptographic term, and it has nothing at all to do with Ethernet
MAC (Media Access Control) addresses, or with the Apple computer.
\H{errors-garbled} \q{Incoming packet was garbled on decryption}
@ -247,10 +250,7 @@ in the server, or in between.
If you get this error, one thing you could try would be to fiddle with
the setting of \q{Miscomputes SSH-2 encryption keys} (see
\k{config-ssh-bug-derivekey2}) or \q{Ignores SSH-2 maximum packet
size} (see \k{config-ssh-bug-maxpkt2}) on the Bugs panel .
Another known server problem which can cause this error is described
in \k{faq-openssh-bad-openssl} in the FAQ.
size} (see \k{config-ssh-bug-maxpkt2}) on the Bugs panel.
\H{errors-x11-proxy} \q{PuTTY X11 proxy: \e{various errors}}

63
doc/faq.but
View File

@ -601,34 +601,6 @@ documentation.)
\H{faq-trouble} Troubleshooting
\S{faq-incorrect-mac}{Question} Why do I see \q{Incorrect MAC
received on packet}?
One possible cause of this that used to be common is a bug in old
SSH-2 servers distributed by \cw{ssh.com}. (This is not the only
possible cause; see \k{errors-crc} in the documentation.)
Version 2.3.0 and below of their SSH-2 server
constructs Message Authentication Codes in the wrong way, and
expects the client to construct them in the same wrong way. PuTTY
constructs the MACs correctly by default, and hence these old
servers will fail to work with it.
If you are using PuTTY version 0.52 or better, this should work
automatically: PuTTY should detect the buggy servers from their
version number announcement, and automatically start to construct
its MACs in the same incorrect manner as they do, so it will be able
to work with them.
If you are using PuTTY version 0.51 or below, you can enable the
workaround by going to the SSH panel and ticking the box labelled
\q{Imitate SSH2 MAC bug}. It's possible that you might have to do
this with 0.52 as well, if a buggy server exists that PuTTY doesn't
know about.
In this context MAC stands for \ii{Message Authentication Code}. It's a
cryptographic term, and it has nothing at all to do with Ethernet
MAC (Media Access Control) addresses.
\S{faq-pscp-protocol}{Question} Why do I see \q{Fatal: Protocol
error: Expected control record} in PSCP?
@ -895,41 +867,6 @@ You should still read the
page} on the PuTTY website (also provided as \k{feedback} in the
manual), and follow the guidelines contained in that.
\S{faq-openssh-bad-openssl}{Question} Since my SSH server was upgraded
to \i{OpenSSH} 3.1p1/3.4p1, I can no longer connect with PuTTY.
There is a known problem when OpenSSH has been built against an
incorrect version of OpenSSL; the quick workaround is to configure
PuTTY to use SSH protocol 2 and the Blowfish cipher.
For more details and OpenSSH patches, see
\W{http://bugzilla.mindrot.org/show_bug.cgi?id=138}{bug 138} in the
OpenSSH BTS.
This is not a PuTTY-specific problem; if you try to connect with
another client you'll likely have similar problems. (Although PuTTY's
default cipher differs from many other clients.)
\e{OpenSSH 3.1p1:} configurations known to be broken (and symptoms):
\b SSH-2 with AES cipher (PuTTY says \q{Assertion failed! Expression:
(len & 15) == 0} in \cw{sshaes.c}, or \q{Out of memory}, or crashes)
\b SSH-2 with 3DES (PuTTY says \q{Incorrect MAC received on packet})
\b SSH-1 with Blowfish (PuTTY says \q{Incorrect CRC received on
packet})
\b SSH-1 with 3DES
\e{OpenSSH 3.4p1:} as of 3.4p1, only the problem with SSH-1 and
Blowfish remains. Rebuild your server, apply the patch linked to from
bug 138 above, or use another cipher (e.g., 3DES) instead.
\e{Other versions:} we occasionally get reports of the same symptom
and workarounds with older versions of OpenSSH, although it's not
clear the underlying cause is the same.
\S{faq-ssh2key-ssh1conn}{Question} Why do I see \q{Couldn't load
private key from ...}? Why can PuTTYgen load my key but not PuTTY?