\define{versioniderrors} \versionid $Id$
-\C{errors} Common error messages
+\C{errors} Common \i{error messages}
This chapter lists a number of common error messages which PuTTY and
its associated tools can produce, and explains what they mean in
If you see this message and you know that your installation of PuTTY
\e{has} connected to the same server before, it may have been
recently upgraded to SSH protocol version 2. SSH protocols 1 and 2
-use separate host keys, so when you first use SSH-2 with a server
+use separate host keys, so when you first use \i{SSH-2} with a server
you have only used SSH-1 with before, you will see this message
again. You should verify the correctness of the key as before.
See \k{gs-hostkey} for more information on host keys.
-\H{errors-portfwd-space} \q{Out of space for port forwardings}
-
-PuTTY has a fixed-size buffer which it uses to store the details of
-all port forwardings you have set up in an SSH session. If you
-specify too many port forwardings on the PuTTY or Plink command line
-and this buffer becomes full, you will see this error message.
-
-We need to fix this (fixed-size buffers are almost always a mistake)
-but we haven't got round to it. If you actually have trouble with
-this, let us know and we'll move it up our priority list.
-
\H{errors-cipher-warning} \q{The first cipher supported by the server is
... below the configured warning threshold}
This occurs when the SSH server does not offer any ciphers which you
have configured PuTTY to consider strong enough. By default, PuTTY
-puts up this warning only for single-DES encryption.
+puts up this warning only for \ii{single-DES} and \i{Arcfour} encryption.
See \k{config-ssh-encryption} for more information on this message.
\H{errors-toomanyauth} \q{Server sent disconnect message type 2
-(SSH_DISCONNECT_PROTOCOL_ERROR): "Too many authentication failures for root"}
+(protocol error): "Too many authentication failures for root"}
-This message is produced by an OpenSSH (or Sun SSH) server if it
+This message is produced by an \i{OpenSSH} (or \i{Sun SSH}) server if it
receives more failed authentication attempts than it is willing to
-tolerate. This can easily happen if you are using Pageant and have a
-large number of keys loaded into it. This can be worked around on the
-server by disabling public-key authentication or (for Sun SSH only) by
-increasing \c{MaxAuthTries} in \c{sshd_config}. Neither of these is a
-really satisfactory solution, and we hope to provide a better one in a
-future version of PuTTY.
+tolerate.
+
+This can easily happen if you are using Pageant and have a
+large number of keys loaded into it, since these servers count each
+offer of a public key as an authentication attempt. This can be worked
+around by specifying the key that's required for the authentication in
+the PuTTY configuration (see \k{config-ssh-privkey}); PuTTY will ignore
+any other keys Pageant may have, but will ask Pageant to do the
+authentication, so that you don't have to type your passphrase.
-\H{errors-memory} \q{Out of memory}
+On the server, this can be worked around by disabling public-key
+authentication or (for Sun SSH only) by increasing \c{MaxAuthTries} in
+\c{sshd_config}.
+
+\H{errors-memory} \q{\ii{Out of memory}}
This occurs when PuTTY tries to allocate more memory than the system
can give it. This \e{may} happen for genuine reasons: if the
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 OpenSSH have a known problem with this: see
+versions of \i{OpenSSH} have a known problem with this: see
\k{faq-openssh-bad-openssl}.
-This can also happen in PSCP or PSFTP, if your login scripts on the
+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
message starting with a length, and if it receives some text from
your login scripts instead it will try to interpret them as a
message length. See \k{faq-outofmem2} for details of this.
-\H{errors-internal} \q{Internal error}, \q{Internal fault},
-\q{Assertion failed}
+\H{errors-internal} \q{\ii{Internal error}}, \q{\ii{Internal fault}},
+\q{\ii{Assertion failed}}
Any error beginning with the word \q{Internal} should \e{never}
occur. If it does, there is a bug in PuTTY by definition; please see
the server may have sent diagnostic messages explaining exactly what
problem it had with your setup.
+\K{pubkey-gettingready} has some hints on server-side public key
+setup.
+
\H{errors-access-denied} \q{Access denied}, \q{Authentication refused}
Various forms of this error are printed in the PuTTY window, or
Upgrade your server, or use the workarounds described in
\k{config-ssh-bug-ignore1} and possibly \k{config-ssh-bug-plainpw1}.
-\H{errors-crc} \q{Incorrect CRC received on packet} or \q{Incorrect
-MAC received on packet}
+\H{errors-no-auth} \q{No supported authentication methods available}
+
+This error indicates that PuTTY has run out of ways to authenticate
+you to an SSH server. This may be because PuTTY has TIS or
+keyboard-interactive authentication disabled, in which case
+\k{config-ssh-tis} and \k{config-ssh-ki}.
+
+\H{errors-crc} \q{Incorrect \i{CRC} received on packet} or \q{Incorrect
+\i{MAC} received on packet}
This error occurs when PuTTY decrypts an SSH packet and its checksum
is not correct. This probably means something has gone wrong in the
error message whether the problem is in the client, in the server,
or in between.
+In particular, if the network is corrupting data at the TCP level, it
+may only be obvious with cryptographic protocols such as SSH, which
+explicitly check the integrity of the transferred data and complain
+loudly if the checks fail. Corruption of protocols without integrity
+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.
to tell from this error message whether the problem is in the client,
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} on the Bugs
-panel (see \k{config-ssh-bug-derivekey2}).
+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.
Ethernet-connected computer, or if Windows has any other similar
reason to believe the entire network has become unreachable.
+Windows also generates this error if it has given up on the machine
+at the other end of the connection ever responding to it. If the
+network between your client and server goes down and your client
+then tries to send some data, Windows will make several attempts to
+send the data and will then give up and kill the connection. In
+particular, this can occur even if you didn't type anything, if you
+are using SSH-2 and PuTTY attempts a key re-exchange. (See
+\k{config-ssh-kex-rekey} for more about key re-exchange.)
+
+(It can also occur if you are using keepalives in your connection.
+Other people have reported that keepalives \e{fix} this error for
+them. See \k{config-keepalive} for a discussion of the pros and cons
+of keepalives.)
+
We are not aware of any reason why this error might occur that would
represent a bug in PuTTY. The problem is between you, your Windows
system, your network and the remote system.
-Some people have reported that enabling keepalives (see
-\k{config-keepalive}) fixes this error for them.
-
\H{errors-connreset} \q{Network error: Connection reset by peer}
This error occurs when the machines at each end of a network
manages to reboot fully before you next attempt to send data to it.
However, the most common reason to see this message is if you are
-connecting through a firewall or a NAT router which has timed the
+connecting through a \i{firewall} or a \i{NAT router} which has timed the
connection out. See \k{faq-idleout} in the FAQ for more details. You
may be able to improve the situation by using keepalives; see
\k{config-keepalive} for details on this.
Check that you have correctly entered the host name or IP address of
your server machine. If that fails, consult the administrator of
your server.
+
+\i{Unix} also generates this error when it tries to send data down a
+connection and contact with the server has been completely lost
+during a connection. (There is a delay of minutes before Unix gives
+up on receiving a reply from the server.) This can occur if you type
+things into PuTTY while the network is down, but it can also occur
+if PuTTY decides of its own accord to send data: due to a repeat key
+exchange in SSH-2 (see \k{config-ssh-kex-rekey}) or due to
+keepalives (\k{config-keepalive}).
~mdw / sgt / putty / blobdiff