--- /dev/null
+\define{versioniderrors} \versionid $Id: errors.but 8897 2010-03-13 14:47:14Z jacob $\r
+\r
+\C{errors} Common \i{error messages}\r
+\r
+This chapter lists a number of common error messages which PuTTY and\r
+its associated tools can produce, and explains what they mean in\r
+more detail.\r
+\r
+We do not attempt to list \e{all} error messages here: there are\r
+many which should never occur, and some which should be\r
+self-explanatory. If you get an error message which is not listed in\r
+this chapter and which you don't understand, report it to us as a\r
+bug (see \k{feedback}) and we will add documentation for it.\r
+\r
+\H{errors-hostkey-absent} \q{The server's host key is not cached in\r
+the registry}\r
+\r
+\cfg{winhelp-topic}{errors.hostkey.absent}\r
+\r
+This error message occurs when PuTTY connects to a new SSH server.\r
+Every server identifies itself by means of a host key; once PuTTY\r
+knows the host key for a server, it will be able to detect if a\r
+malicious attacker redirects your connection to another machine.\r
+\r
+If you see this message, it means that PuTTY has not seen this host\r
+key before, and has no way of knowing whether it is correct or not.\r
+You should attempt to verify the host key by other means, such as\r
+asking the machine's administrator.\r
+\r
+If you see this message and you know that your installation of PuTTY\r
+\e{has} connected to the same server before, it may have been\r
+recently upgraded to SSH protocol version 2. SSH protocols 1 and 2\r
+use separate host keys, so when you first use \i{SSH-2} with a server\r
+you have only used SSH-1 with before, you will see this message\r
+again. You should verify the correctness of the key as before.\r
+\r
+See \k{gs-hostkey} for more information on host keys.\r
+\r
+\H{errors-hostkey-wrong} \q{WARNING - POTENTIAL SECURITY BREACH!}\r
+\r
+\cfg{winhelp-topic}{errors.hostkey.changed}\r
+\r
+This message, followed by \q{The server's host key does not match\r
+the one PuTTY has cached in the registry}, means that PuTTY has\r
+connected to the SSH server before, knows what its host key\r
+\e{should} be, but has found a different one.\r
+\r
+This may mean that a malicious attacker has replaced your server\r
+with a different one, or has redirected your network connection to\r
+their own machine. On the other hand, it may simply mean that the\r
+administrator of your server has accidentally changed the key while\r
+upgrading the SSH software; this \e{shouldn't} happen but it is\r
+unfortunately possible.\r
+\r
+You should contact your server's administrator and see whether they\r
+expect the host key to have changed. If so, verify the new host key\r
+in the same way as you would if it was new.\r
+\r
+See \k{gs-hostkey} for more information on host keys.\r
+\r
+\H{errors-portfwd-space} \q{Out of space for port forwardings}\r
+\r
+PuTTY has a fixed-size buffer which it uses to store the details of\r
+all \i{port forwardings} you have set up in an SSH session. If you\r
+specify too many port forwardings on the PuTTY or Plink command line\r
+and this buffer becomes full, you will see this error message.\r
+\r
+We need to fix this (fixed-size buffers are almost always a mistake)\r
+but we haven't got round to it. If you actually have trouble with\r
+this, let us know and we'll move it up our priority list.\r
+\r
+If you're running into this limit, you may want to consider using\r
+dynamic port forwarding instead; see \k{using-port-forwarding}.\r
+\r
+\H{errors-cipher-warning} \q{The first cipher supported by the server is\r
+... below the configured warning threshold}\r
+\r
+This occurs when the SSH server does not offer any ciphers which you\r
+have configured PuTTY to consider strong enough. By default, PuTTY\r
+puts up this warning only for \ii{single-DES} and \i{Arcfour} encryption.\r
+\r
+See \k{config-ssh-encryption} for more information on this message.\r
+\r
+\H{errors-toomanyauth} \q{Server sent disconnect message type 2\r
+(protocol error): "Too many authentication failures for root"}\r
+\r
+This message is produced by an \i{OpenSSH} (or \i{Sun SSH}) server if it\r
+receives more failed authentication attempts than it is willing to\r
+tolerate.\r
+\r
+This can easily happen if you are using Pageant and have a\r
+large number of keys loaded into it, since these servers count each\r
+offer of a public key as an authentication attempt. This can be worked\r
+around by specifying the key that's required for the authentication in\r
+the PuTTY configuration (see \k{config-ssh-privkey}); PuTTY will ignore\r
+any other keys Pageant may have, but will ask Pageant to do the\r
+authentication, so that you don't have to type your passphrase.\r
+\r
+On the server, this can be worked around by disabling public-key\r
+authentication or (for Sun SSH only) by increasing \c{MaxAuthTries} in\r
+\c{sshd_config}.\r
+\r
+\H{errors-memory} \q{\ii{Out of memory}}\r
+\r
+This occurs when PuTTY tries to allocate more memory than the system\r
+can give it. This \e{may} happen for genuine reasons: if the\r
+computer really has run out of memory, or if you have configured an\r
+extremely large number of lines of scrollback in your terminal.\r
+PuTTY is not able to recover from running out of memory; it will\r
+terminate immediately after giving this error.\r
+\r
+However, this error can also occur when memory is not running out at\r
+all, because PuTTY receives data in the wrong format. In SSH-2 and\r
+also in SFTP, the server sends the length of each message before the\r
+message itself; so PuTTY will receive the length, try to allocate\r
+space for the message, and then receive the rest of the message. If\r
+the length PuTTY receives is garbage, it will try to allocate a\r
+ridiculous amount of memory, and will terminate with an \q{Out of\r
+memory} error.\r
+\r
+This can happen in SSH-2, if PuTTY and the server have not enabled\r
+encryption in the same way (see \k{faq-outofmem} in the FAQ). Some\r
+versions of \i{OpenSSH} have a known problem with this: see\r
+\k{faq-openssh-bad-openssl}.\r
+\r
+This can also happen in PSCP or PSFTP, if your \i{login scripts} on the\r
+server generate output: the client program will be expecting an SFTP\r
+message starting with a length, and if it receives some text from\r
+your login scripts instead it will try to interpret them as a\r
+message length. See \k{faq-outofmem2} for details of this.\r
+\r
+\H{errors-internal} \q{\ii{Internal error}}, \q{\ii{Internal fault}},\r
+\q{\ii{Assertion failed}}\r
+\r
+Any error beginning with the word \q{Internal} should \e{never}\r
+occur. If it does, there is a bug in PuTTY by definition; please see\r
+\k{feedback} and report it to us.\r
+\r
+Similarly, any error message starting with \q{Assertion failed} is a\r
+bug in PuTTY. Please report it to us, and include the exact text\r
+from the error message box.\r
+\r
+\H{errors-cant-load-key} \q{Unable to use this private key file},\r
+\q{Couldn't load private key}, \q{Key is of wrong type}\r
+\r
+\cfg{winhelp-topic}{errors.cantloadkey}\r
+\r
+Various forms of this error are printed in the PuTTY window, or\r
+written to the PuTTY Event Log (see \k{using-eventlog}) when trying\r
+public-key authentication, or given by Pageant when trying to load a\r
+private key.\r
+\r
+If you see one of these messages, it often indicates that you've tried\r
+to load a key of an inappropriate type into PuTTY, Plink, PSCP, PSFTP,\r
+or Pageant.\r
+\r
+You may have specified a key that's inappropriate for the connection\r
+you're making. The SSH-1 and SSH-2 protocols require different private\r
+key formats, and a SSH-1 key can't be used for a SSH-2 connection (or\r
+vice versa).\r
+\r
+Alternatively, you may have tried to load an SSH-2 key in a \q{foreign}\r
+format (OpenSSH or \cw{ssh.com}) directly into one of the PuTTY tools,\r
+in which case you need to import it into PuTTY's native format\r
+(\c{*.PPK}) using PuTTYgen - see \k{puttygen-conversions}.\r
+\r
+\H{errors-refused} \q{Server refused our public key} or \q{Key\r
+refused}\r
+\r
+Various forms of this error are printed in the PuTTY window, or\r
+written to the PuTTY Event Log (see \k{using-eventlog}) when trying\r
+public-key authentication.\r
+\r
+If you see one of these messages, it means that PuTTY has sent a\r
+public key to the server and offered to authenticate with it, and\r
+the server has refused to accept authentication. This usually means\r
+that the server is not configured to accept this key to authenticate\r
+this user.\r
+\r
+This is almost certainly not a problem with PuTTY. If you see this\r
+type of message, the first thing you should do is check your\r
+\e{server} configuration carefully. Common errors include having\r
+the wrong permissions or ownership set on the public key or the\r
+user's home directory on the server. Also, read the PuTTY Event Log;\r
+the server may have sent diagnostic messages explaining exactly what\r
+problem it had with your setup.\r
+\r
+\K{pubkey-gettingready} has some hints on server-side public key\r
+setup.\r
+\r
+\H{errors-access-denied} \q{Access denied}, \q{Authentication refused}\r
+\r
+Various forms of this error are printed in the PuTTY window, or\r
+written to the PuTTY Event Log (see \k{using-eventlog}) during\r
+authentication.\r
+\r
+If you see one of these messages, it means that the server has refused \r
+all the forms of authentication PuTTY has tried and it has no further\r
+ideas.\r
+\r
+It may be worth checking the Event Log for diagnostic messages from\r
+the server giving more detail.\r
+\r
+This error can be caused by buggy SSH-1 servers that fail to cope with\r
+the various strategies we use for camouflaging passwords in transit.\r
+Upgrade your server, or use the workarounds described in\r
+\k{config-ssh-bug-ignore1} and possibly \k{config-ssh-bug-plainpw1}.\r
+\r
+\H{errors-no-auth} \q{No supported authentication methods available}\r
+\r
+This error indicates that PuTTY has run out of ways to authenticate\r
+you to an SSH server. This may be because PuTTY has TIS or\r
+keyboard-interactive authentication disabled, in which case\r
+\k{config-ssh-tis} and \k{config-ssh-ki}.\r
+\r
+\H{errors-crc} \q{Incorrect \i{CRC} received on packet} or \q{Incorrect\r
+\i{MAC} received on packet}\r
+\r
+This error occurs when PuTTY decrypts an SSH packet and its checksum\r
+is not correct. This probably means something has gone wrong in the\r
+encryption or decryption process. It's difficult to tell from this\r
+error message whether the problem is in the client, in the server,\r
+or in between.\r
+\r
+In particular, if the network is corrupting data at the TCP level, it\r
+may only be obvious with cryptographic protocols such as SSH, which\r
+explicitly check the integrity of the transferred data and complain\r
+loudly if the checks fail. Corruption of protocols without integrity\r
+protection (such as HTTP) will manifest in more subtle failures (such\r
+as misdisplayed text or images in a web browser) which may not be\r
+noticed.\r
+\r
+A known server problem which can cause this error is described in\r
+\k{faq-openssh-bad-openssl} in the FAQ.\r
+\r
+\H{errors-garbled} \q{Incoming packet was garbled on decryption}\r
+\r
+This error occurs when PuTTY decrypts an SSH packet and the\r
+decrypted data makes no sense. This probably means something has\r
+gone wrong in the encryption or decryption process. It's difficult\r
+to tell from this error message whether the problem is in the client,\r
+in the server, or in between.\r
+\r
+If you get this error, one thing you could try would be to fiddle with\r
+the setting of \q{Miscomputes SSH-2 encryption keys} (see\r
+\k{config-ssh-bug-derivekey2}) or \q{Ignores SSH-2 maximum packet\r
+size} (see \k{config-ssh-bug-maxpkt2}) on the Bugs panel .\r
+\r
+Another known server problem which can cause this error is described\r
+in \k{faq-openssh-bad-openssl} in the FAQ.\r
+\r
+\H{errors-x11-proxy} \q{PuTTY X11 proxy: \e{various errors}}\r
+\r
+This family of errors are reported when PuTTY is doing X forwarding.\r
+They are sent back to the X application running on the SSH server,\r
+which will usually report the error to the user.\r
+\r
+When PuTTY enables X forwarding (see \k{using-x-forwarding}) it\r
+creates a virtual X display running on the SSH server. This display\r
+requires authentication to connect to it (this is how PuTTY prevents\r
+other users on your server machine from connecting through the PuTTY\r
+proxy to your real X display). PuTTY also sends the server the\r
+details it needs to enable clients to connect, and the server should\r
+put this mechanism in place automatically, so your X applications\r
+should just work.\r
+\r
+A common reason why people see one of these messages is because they\r
+used SSH to log in as one user (let's say \q{fred}), and then used\r
+the Unix \c{su} command to become another user (typically \q{root}).\r
+The original user, \q{fred}, has access to the X authentication data\r
+provided by the SSH server, and can run X applications which are\r
+forwarded over the SSH connection. However, the second user\r
+(\q{root}) does not automatically have the authentication data\r
+passed on to it, so attempting to run an X application as that user\r
+often fails with this error.\r
+\r
+If this happens, \e{it is not a problem with PuTTY}. You need to\r
+arrange for your X authentication data to be passed from the user\r
+you logged in as to the user you used \c{su} to become. How you do\r
+this depends on your particular system; in fact many modern versions\r
+of \c{su} do it automatically.\r
+\r
+\H{errors-connaborted} \q{Network error: Software caused connection\r
+abort}\r
+\r
+This is a generic error produced by the Windows network code when it\r
+kills an established connection for some reason. For example, it might\r
+happen if you pull the network cable out of the back of an\r
+Ethernet-connected computer, or if Windows has any other similar\r
+reason to believe the entire network has become unreachable.\r
+\r
+Windows also generates this error if it has given up on the machine\r
+at the other end of the connection ever responding to it. If the\r
+network between your client and server goes down and your client\r
+then tries to send some data, Windows will make several attempts to\r
+send the data and will then give up and kill the connection. In\r
+particular, this can occur even if you didn't type anything, if you\r
+are using SSH-2 and PuTTY attempts a key re-exchange. (See\r
+\k{config-ssh-kex-rekey} for more about key re-exchange.)\r
+\r
+(It can also occur if you are using keepalives in your connection.\r
+Other people have reported that keepalives \e{fix} this error for\r
+them. See \k{config-keepalive} for a discussion of the pros and cons\r
+of keepalives.)\r
+\r
+We are not aware of any reason why this error might occur that would\r
+represent a bug in PuTTY. The problem is between you, your Windows\r
+system, your network and the remote system.\r
+\r
+\H{errors-connreset} \q{Network error: Connection reset by peer}\r
+\r
+This error occurs when the machines at each end of a network\r
+connection lose track of the state of the connection between them.\r
+For example, you might see it if your SSH server crashes, and\r
+manages to reboot fully before you next attempt to send data to it.\r
+\r
+However, the most common reason to see this message is if you are\r
+connecting through a \i{firewall} or a \i{NAT router} which has timed the\r
+connection out. See \k{faq-idleout} in the FAQ for more details. You\r
+may be able to improve the situation by using keepalives; see\r
+\k{config-keepalive} for details on this.\r
+\r
+Note that Windows can produce this error in some circumstances without\r
+seeing a connection reset from the server, for instance if the\r
+connection to the network is lost.\r
+\r
+\H{errors-connrefused} \q{Network error: Connection refused}\r
+\r
+This error means that the network connection PuTTY tried to make to\r
+your server was rejected by the server. Usually this happens because\r
+the server does not provide the service which PuTTY is trying to\r
+access.\r
+\r
+Check that you are connecting with the correct protocol (SSH, Telnet\r
+or Rlogin), and check that the port number is correct. If that\r
+fails, consult the administrator of your server.\r
+\r
+\H{errors-conntimedout} \q{Network error: Connection timed out}\r
+\r
+This error means that the network connection PuTTY tried to make to\r
+your server received no response at all from the server. Usually\r
+this happens because the server machine is completely isolated from\r
+the network, or because it is turned off.\r
+\r
+Check that you have correctly entered the host name or IP address of\r
+your server machine. If that fails, consult the administrator of\r
+your server.\r
+\r
+\i{Unix} also generates this error when it tries to send data down a\r
+connection and contact with the server has been completely lost\r
+during a connection. (There is a delay of minutes before Unix gives\r
+up on receiving a reply from the server.) This can occur if you type\r
+things into PuTTY while the network is down, but it can also occur\r
+if PuTTY decides of its own accord to send data: due to a repeat key\r
+exchange in SSH-2 (see \k{config-ssh-kex-rekey}) or due to\r
+keepalives (\k{config-keepalive}).\r
OSDN Git Service
