1 \define{versioniderrors} \versionid $Id: errors.but 8897 2010-03-13 14:47:14Z jacob $
\r
3 \C{errors} Common \i{error messages}
\r
5 This chapter lists a number of common error messages which PuTTY and
\r
6 its associated tools can produce, and explains what they mean in
\r
9 We do not attempt to list \e{all} error messages here: there are
\r
10 many which should never occur, and some which should be
\r
11 self-explanatory. If you get an error message which is not listed in
\r
12 this chapter and which you don't understand, report it to us as a
\r
13 bug (see \k{feedback}) and we will add documentation for it.
\r
15 \H{errors-hostkey-absent} \q{The server's host key is not cached in
\r
18 \cfg{winhelp-topic}{errors.hostkey.absent}
\r
20 This error message occurs when PuTTY connects to a new SSH server.
\r
21 Every server identifies itself by means of a host key; once PuTTY
\r
22 knows the host key for a server, it will be able to detect if a
\r
23 malicious attacker redirects your connection to another machine.
\r
25 If you see this message, it means that PuTTY has not seen this host
\r
26 key before, and has no way of knowing whether it is correct or not.
\r
27 You should attempt to verify the host key by other means, such as
\r
28 asking the machine's administrator.
\r
30 If you see this message and you know that your installation of PuTTY
\r
31 \e{has} connected to the same server before, it may have been
\r
32 recently upgraded to SSH protocol version 2. SSH protocols 1 and 2
\r
33 use separate host keys, so when you first use \i{SSH-2} with a server
\r
34 you have only used SSH-1 with before, you will see this message
\r
35 again. You should verify the correctness of the key as before.
\r
37 See \k{gs-hostkey} for more information on host keys.
\r
39 \H{errors-hostkey-wrong} \q{WARNING - POTENTIAL SECURITY BREACH!}
\r
41 \cfg{winhelp-topic}{errors.hostkey.changed}
\r
43 This message, followed by \q{The server's host key does not match
\r
44 the one PuTTY has cached in the registry}, means that PuTTY has
\r
45 connected to the SSH server before, knows what its host key
\r
46 \e{should} be, but has found a different one.
\r
48 This may mean that a malicious attacker has replaced your server
\r
49 with a different one, or has redirected your network connection to
\r
50 their own machine. On the other hand, it may simply mean that the
\r
51 administrator of your server has accidentally changed the key while
\r
52 upgrading the SSH software; this \e{shouldn't} happen but it is
\r
53 unfortunately possible.
\r
55 You should contact your server's administrator and see whether they
\r
56 expect the host key to have changed. If so, verify the new host key
\r
57 in the same way as you would if it was new.
\r
59 See \k{gs-hostkey} for more information on host keys.
\r
61 \H{errors-portfwd-space} \q{Out of space for port forwardings}
\r
63 PuTTY has a fixed-size buffer which it uses to store the details of
\r
64 all \i{port forwardings} you have set up in an SSH session. If you
\r
65 specify too many port forwardings on the PuTTY or Plink command line
\r
66 and this buffer becomes full, you will see this error message.
\r
68 We need to fix this (fixed-size buffers are almost always a mistake)
\r
69 but we haven't got round to it. If you actually have trouble with
\r
70 this, let us know and we'll move it up our priority list.
\r
72 If you're running into this limit, you may want to consider using
\r
73 dynamic port forwarding instead; see \k{using-port-forwarding}.
\r
75 \H{errors-cipher-warning} \q{The first cipher supported by the server is
\r
76 ... below the configured warning threshold}
\r
78 This occurs when the SSH server does not offer any ciphers which you
\r
79 have configured PuTTY to consider strong enough. By default, PuTTY
\r
80 puts up this warning only for \ii{single-DES} and \i{Arcfour} encryption.
\r
82 See \k{config-ssh-encryption} for more information on this message.
\r
84 \H{errors-toomanyauth} \q{Server sent disconnect message type 2
\r
85 (protocol error): "Too many authentication failures for root"}
\r
87 This message is produced by an \i{OpenSSH} (or \i{Sun SSH}) server if it
\r
88 receives more failed authentication attempts than it is willing to
\r
91 This can easily happen if you are using Pageant and have a
\r
92 large number of keys loaded into it, since these servers count each
\r
93 offer of a public key as an authentication attempt. This can be worked
\r
94 around by specifying the key that's required for the authentication in
\r
95 the PuTTY configuration (see \k{config-ssh-privkey}); PuTTY will ignore
\r
96 any other keys Pageant may have, but will ask Pageant to do the
\r
97 authentication, so that you don't have to type your passphrase.
\r
99 On the server, this can be worked around by disabling public-key
\r
100 authentication or (for Sun SSH only) by increasing \c{MaxAuthTries} in
\r
103 \H{errors-memory} \q{\ii{Out of memory}}
\r
105 This occurs when PuTTY tries to allocate more memory than the system
\r
106 can give it. This \e{may} happen for genuine reasons: if the
\r
107 computer really has run out of memory, or if you have configured an
\r
108 extremely large number of lines of scrollback in your terminal.
\r
109 PuTTY is not able to recover from running out of memory; it will
\r
110 terminate immediately after giving this error.
\r
112 However, this error can also occur when memory is not running out at
\r
113 all, because PuTTY receives data in the wrong format. In SSH-2 and
\r
114 also in SFTP, the server sends the length of each message before the
\r
115 message itself; so PuTTY will receive the length, try to allocate
\r
116 space for the message, and then receive the rest of the message. If
\r
117 the length PuTTY receives is garbage, it will try to allocate a
\r
118 ridiculous amount of memory, and will terminate with an \q{Out of
\r
121 This can happen in SSH-2, if PuTTY and the server have not enabled
\r
122 encryption in the same way (see \k{faq-outofmem} in the FAQ). Some
\r
123 versions of \i{OpenSSH} have a known problem with this: see
\r
124 \k{faq-openssh-bad-openssl}.
\r
126 This can also happen in PSCP or PSFTP, if your \i{login scripts} on the
\r
127 server generate output: the client program will be expecting an SFTP
\r
128 message starting with a length, and if it receives some text from
\r
129 your login scripts instead it will try to interpret them as a
\r
130 message length. See \k{faq-outofmem2} for details of this.
\r
132 \H{errors-internal} \q{\ii{Internal error}}, \q{\ii{Internal fault}},
\r
133 \q{\ii{Assertion failed}}
\r
135 Any error beginning with the word \q{Internal} should \e{never}
\r
136 occur. If it does, there is a bug in PuTTY by definition; please see
\r
137 \k{feedback} and report it to us.
\r
139 Similarly, any error message starting with \q{Assertion failed} is a
\r
140 bug in PuTTY. Please report it to us, and include the exact text
\r
141 from the error message box.
\r
143 \H{errors-cant-load-key} \q{Unable to use this private key file},
\r
144 \q{Couldn't load private key}, \q{Key is of wrong type}
\r
146 \cfg{winhelp-topic}{errors.cantloadkey}
\r
148 Various forms of this error are printed in the PuTTY window, or
\r
149 written to the PuTTY Event Log (see \k{using-eventlog}) when trying
\r
150 public-key authentication, or given by Pageant when trying to load a
\r
153 If you see one of these messages, it often indicates that you've tried
\r
154 to load a key of an inappropriate type into PuTTY, Plink, PSCP, PSFTP,
\r
157 You may have specified a key that's inappropriate for the connection
\r
158 you're making. The SSH-1 and SSH-2 protocols require different private
\r
159 key formats, and a SSH-1 key can't be used for a SSH-2 connection (or
\r
162 Alternatively, you may have tried to load an SSH-2 key in a \q{foreign}
\r
163 format (OpenSSH or \cw{ssh.com}) directly into one of the PuTTY tools,
\r
164 in which case you need to import it into PuTTY's native format
\r
165 (\c{*.PPK}) using PuTTYgen - see \k{puttygen-conversions}.
\r
167 \H{errors-refused} \q{Server refused our public key} or \q{Key
\r
170 Various forms of this error are printed in the PuTTY window, or
\r
171 written to the PuTTY Event Log (see \k{using-eventlog}) when trying
\r
172 public-key authentication.
\r
174 If you see one of these messages, it means that PuTTY has sent a
\r
175 public key to the server and offered to authenticate with it, and
\r
176 the server has refused to accept authentication. This usually means
\r
177 that the server is not configured to accept this key to authenticate
\r
180 This is almost certainly not a problem with PuTTY. If you see this
\r
181 type of message, the first thing you should do is check your
\r
182 \e{server} configuration carefully. Common errors include having
\r
183 the wrong permissions or ownership set on the public key or the
\r
184 user's home directory on the server. Also, read the PuTTY Event Log;
\r
185 the server may have sent diagnostic messages explaining exactly what
\r
186 problem it had with your setup.
\r
188 \K{pubkey-gettingready} has some hints on server-side public key
\r
191 \H{errors-access-denied} \q{Access denied}, \q{Authentication refused}
\r
193 Various forms of this error are printed in the PuTTY window, or
\r
194 written to the PuTTY Event Log (see \k{using-eventlog}) during
\r
197 If you see one of these messages, it means that the server has refused
\r
198 all the forms of authentication PuTTY has tried and it has no further
\r
201 It may be worth checking the Event Log for diagnostic messages from
\r
202 the server giving more detail.
\r
204 This error can be caused by buggy SSH-1 servers that fail to cope with
\r
205 the various strategies we use for camouflaging passwords in transit.
\r
206 Upgrade your server, or use the workarounds described in
\r
207 \k{config-ssh-bug-ignore1} and possibly \k{config-ssh-bug-plainpw1}.
\r
209 \H{errors-no-auth} \q{No supported authentication methods available}
\r
211 This error indicates that PuTTY has run out of ways to authenticate
\r
212 you to an SSH server. This may be because PuTTY has TIS or
\r
213 keyboard-interactive authentication disabled, in which case
\r
214 \k{config-ssh-tis} and \k{config-ssh-ki}.
\r
216 \H{errors-crc} \q{Incorrect \i{CRC} received on packet} or \q{Incorrect
\r
217 \i{MAC} received on packet}
\r
219 This error occurs when PuTTY decrypts an SSH packet and its checksum
\r
220 is not correct. This probably means something has gone wrong in the
\r
221 encryption or decryption process. It's difficult to tell from this
\r
222 error message whether the problem is in the client, in the server,
\r
225 In particular, if the network is corrupting data at the TCP level, it
\r
226 may only be obvious with cryptographic protocols such as SSH, which
\r
227 explicitly check the integrity of the transferred data and complain
\r
228 loudly if the checks fail. Corruption of protocols without integrity
\r
229 protection (such as HTTP) will manifest in more subtle failures (such
\r
230 as misdisplayed text or images in a web browser) which may not be
\r
233 A known server problem which can cause this error is described in
\r
234 \k{faq-openssh-bad-openssl} in the FAQ.
\r
236 \H{errors-garbled} \q{Incoming packet was garbled on decryption}
\r
238 This error occurs when PuTTY decrypts an SSH packet and the
\r
239 decrypted data makes no sense. This probably means something has
\r
240 gone wrong in the encryption or decryption process. It's difficult
\r
241 to tell from this error message whether the problem is in the client,
\r
242 in the server, or in between.
\r
244 If you get this error, one thing you could try would be to fiddle with
\r
245 the setting of \q{Miscomputes SSH-2 encryption keys} (see
\r
246 \k{config-ssh-bug-derivekey2}) or \q{Ignores SSH-2 maximum packet
\r
247 size} (see \k{config-ssh-bug-maxpkt2}) on the Bugs panel .
\r
249 Another known server problem which can cause this error is described
\r
250 in \k{faq-openssh-bad-openssl} in the FAQ.
\r
252 \H{errors-x11-proxy} \q{PuTTY X11 proxy: \e{various errors}}
\r
254 This family of errors are reported when PuTTY is doing X forwarding.
\r
255 They are sent back to the X application running on the SSH server,
\r
256 which will usually report the error to the user.
\r
258 When PuTTY enables X forwarding (see \k{using-x-forwarding}) it
\r
259 creates a virtual X display running on the SSH server. This display
\r
260 requires authentication to connect to it (this is how PuTTY prevents
\r
261 other users on your server machine from connecting through the PuTTY
\r
262 proxy to your real X display). PuTTY also sends the server the
\r
263 details it needs to enable clients to connect, and the server should
\r
264 put this mechanism in place automatically, so your X applications
\r
267 A common reason why people see one of these messages is because they
\r
268 used SSH to log in as one user (let's say \q{fred}), and then used
\r
269 the Unix \c{su} command to become another user (typically \q{root}).
\r
270 The original user, \q{fred}, has access to the X authentication data
\r
271 provided by the SSH server, and can run X applications which are
\r
272 forwarded over the SSH connection. However, the second user
\r
273 (\q{root}) does not automatically have the authentication data
\r
274 passed on to it, so attempting to run an X application as that user
\r
275 often fails with this error.
\r
277 If this happens, \e{it is not a problem with PuTTY}. You need to
\r
278 arrange for your X authentication data to be passed from the user
\r
279 you logged in as to the user you used \c{su} to become. How you do
\r
280 this depends on your particular system; in fact many modern versions
\r
281 of \c{su} do it automatically.
\r
283 \H{errors-connaborted} \q{Network error: Software caused connection
\r
286 This is a generic error produced by the Windows network code when it
\r
287 kills an established connection for some reason. For example, it might
\r
288 happen if you pull the network cable out of the back of an
\r
289 Ethernet-connected computer, or if Windows has any other similar
\r
290 reason to believe the entire network has become unreachable.
\r
292 Windows also generates this error if it has given up on the machine
\r
293 at the other end of the connection ever responding to it. If the
\r
294 network between your client and server goes down and your client
\r
295 then tries to send some data, Windows will make several attempts to
\r
296 send the data and will then give up and kill the connection. In
\r
297 particular, this can occur even if you didn't type anything, if you
\r
298 are using SSH-2 and PuTTY attempts a key re-exchange. (See
\r
299 \k{config-ssh-kex-rekey} for more about key re-exchange.)
\r
301 (It can also occur if you are using keepalives in your connection.
\r
302 Other people have reported that keepalives \e{fix} this error for
\r
303 them. See \k{config-keepalive} for a discussion of the pros and cons
\r
306 We are not aware of any reason why this error might occur that would
\r
307 represent a bug in PuTTY. The problem is between you, your Windows
\r
308 system, your network and the remote system.
\r
310 \H{errors-connreset} \q{Network error: Connection reset by peer}
\r
312 This error occurs when the machines at each end of a network
\r
313 connection lose track of the state of the connection between them.
\r
314 For example, you might see it if your SSH server crashes, and
\r
315 manages to reboot fully before you next attempt to send data to it.
\r
317 However, the most common reason to see this message is if you are
\r
318 connecting through a \i{firewall} or a \i{NAT router} which has timed the
\r
319 connection out. See \k{faq-idleout} in the FAQ for more details. You
\r
320 may be able to improve the situation by using keepalives; see
\r
321 \k{config-keepalive} for details on this.
\r
323 Note that Windows can produce this error in some circumstances without
\r
324 seeing a connection reset from the server, for instance if the
\r
325 connection to the network is lost.
\r
327 \H{errors-connrefused} \q{Network error: Connection refused}
\r
329 This error means that the network connection PuTTY tried to make to
\r
330 your server was rejected by the server. Usually this happens because
\r
331 the server does not provide the service which PuTTY is trying to
\r
334 Check that you are connecting with the correct protocol (SSH, Telnet
\r
335 or Rlogin), and check that the port number is correct. If that
\r
336 fails, consult the administrator of your server.
\r
338 \H{errors-conntimedout} \q{Network error: Connection timed out}
\r
340 This error means that the network connection PuTTY tried to make to
\r
341 your server received no response at all from the server. Usually
\r
342 this happens because the server machine is completely isolated from
\r
343 the network, or because it is turned off.
\r
345 Check that you have correctly entered the host name or IP address of
\r
346 your server machine. If that fails, consult the administrator of
\r
349 \i{Unix} also generates this error when it tries to send data down a
\r
350 connection and contact with the server has been completely lost
\r
351 during a connection. (There is a delay of minutes before Unix gives
\r
352 up on receiving a reply from the server.) This can occur if you type
\r
353 things into PuTTY while the network is down, but it can also occur
\r
354 if PuTTY decides of its own accord to send data: due to a repeat key
\r
355 exchange in SSH-2 (see \k{config-ssh-kex-rekey}) or due to
\r
356 keepalives (\k{config-keepalive}).
\r
OSDN Git Service
