| 1 | \define{versioniderrors} \versionid $Id$ |
| 2 | |
| 3 | \C{errors} Common error messages |
| 4 | |
| 5 | This chapter lists a number of common error messages which PuTTY and |
| 6 | its associated tools can produce, and explains what they mean in |
| 7 | more detail. |
| 8 | |
| 9 | We do not attempt to list \e{all} error messages here: there are |
| 10 | many which should never occur, and some which should be |
| 11 | self-explanatory. If you get an error message which is not listed in |
| 12 | this chapter and which you don't understand, report it to us as a |
| 13 | bug (see \k{feedback}) and we will add documentation for it. |
| 14 | |
| 15 | \H{errors-hostkey-absent} \q{The server's host key is not cached in |
| 16 | the registry} |
| 17 | |
| 18 | \cfg{winhelp-topic}{errors.hostkey.absent} |
| 19 | |
| 20 | This error message occurs when PuTTY connects to a new SSH server. |
| 21 | Every server identifies itself by means of a host key; once PuTTY |
| 22 | knows the host key for a server, it will be able to detect if a |
| 23 | malicious attacker redirects your connection to another machine. |
| 24 | |
| 25 | If you see this message, it means that PuTTY has not seen this host |
| 26 | key before, and has no way of knowing whether it is correct or not. |
| 27 | You should attempt to verify the host key by other means, such as |
| 28 | asking the machine's administrator. |
| 29 | |
| 30 | If you see this message and you know that your installation of PuTTY |
| 31 | \e{has} connected to the same server before, it may have been |
| 32 | recently upgraded to SSH protocol version 2. SSH protocols 1 and 2 |
| 33 | use separate host keys, so when you first use SSH 2 with a server |
| 34 | you have only used SSH 1 with before, you will see this message |
| 35 | again. You should verify the correctness of the key as before. |
| 36 | |
| 37 | See \k{gs-hostkey} for more information on host keys. |
| 38 | |
| 39 | \H{errors-hostkey-wrong} \q{WARNING - POTENTIAL SECURITY BREACH!} |
| 40 | |
| 41 | \cfg{winhelp-topic}{errors.hostkey.changed} |
| 42 | |
| 43 | This message, followed by \q{The server's host key does not match |
| 44 | the one PuTTY has cached in the registry}, means that PuTTY has |
| 45 | connected to the SSH server before, knows what its host key |
| 46 | \e{should} be, but has found a different one. |
| 47 | |
| 48 | This may mean that a malicious attacker has replaced your server |
| 49 | with a different one, or has redirected your network connection to |
| 50 | their own machine. On the other hand, it may simply mean that the |
| 51 | administrator of your server has accidentally changed the key while |
| 52 | upgrading the SSH software; this \e{shouldn't} happen but it is |
| 53 | unfortunately possible. |
| 54 | |
| 55 | You should contact your server's administrator and see whether they |
| 56 | expect the host key to have changed. If so, verify the new host key |
| 57 | in the same way as you would if it was new. |
| 58 | |
| 59 | See \k{gs-hostkey} for more information on host keys. |
| 60 | |
| 61 | \H{errors-portfwd-space} \q{Out of space for port forwardings} |
| 62 | |
| 63 | PuTTY has a fixed-size buffer which it uses to store the details of |
| 64 | all port forwardings you have set up in an SSH session. If you |
| 65 | specify too many port forwardings on the PuTTY or Plink command line |
| 66 | and this buffer becomes full, you will see this error message. |
| 67 | |
| 68 | We need to fix this (fixed-size buffers are almost always a mistake) |
| 69 | but we haven't got round to it. If you actually have trouble with |
| 70 | this, let us know and we'll move it up our priority list. |
| 71 | |
| 72 | \H{errors-cipher-warning} \q{The first cipher supported by the server is |
| 73 | ... below the configured warning threshold} |
| 74 | |
| 75 | This occurs when the SSH server does not offer any ciphers which you |
| 76 | have configured PuTTY to consider strong enough. By default, PuTTY |
| 77 | puts up this warning only for single-DES encryption. |
| 78 | |
| 79 | See \k{config-ssh-encryption} for more information on this message. |
| 80 | |
| 81 | \H{errors-toomanyauth} \q{Server sent disconnect message type 2 |
| 82 | (SSH_DISCONNECT_PROTOCOL_ERROR): "Too many authentication failures for root"} |
| 83 | |
| 84 | This message is produced by an OpenSSH (or Sun SSH) server if it |
| 85 | receives more failed authentication attempts than it is willing to |
| 86 | tolerate. This can easily happen if you are using Pageant and have a |
| 87 | large number of keys loaded into it. This can be worked around on the |
| 88 | server by disabling public-key authentication or (for Sun SSH only) by |
| 89 | increasing \c{MaxAuthTries} in \c{sshd_config}. Neither of these is a |
| 90 | really satisfactory solution, and we hope to provide a better one in a |
| 91 | future version of PuTTY. |
| 92 | |
| 93 | \H{errors-memory} \q{Out of memory} |
| 94 | |
| 95 | This occurs when PuTTY tries to allocate more memory than the system |
| 96 | can give it. This \e{may} happen for genuine reasons: if the |
| 97 | computer really has run out of memory, or if you have configured an |
| 98 | extremely large number of lines of scrollback in your terminal. |
| 99 | PuTTY is not able to recover from running out of memory; it will |
| 100 | terminate immediately after giving this error. |
| 101 | |
| 102 | However, this error can also occur when memory is not running out at |
| 103 | all, because PuTTY receives data in the wrong format. In SSH 2 and |
| 104 | also in SFTP, the server sends the length of each message before the |
| 105 | message itself; so PuTTY will receive the length, try to allocate |
| 106 | space for the message, and then receive the rest of the message. If |
| 107 | the length PuTTY receives is garbage, it will try to allocate a |
| 108 | ridiculous amount of memory, and will terminate with an \q{Out of |
| 109 | memory} error. |
| 110 | |
| 111 | This can happen in SSH 2, if PuTTY and the server have not enabled |
| 112 | encryption in the same way (see \k{faq-outofmem} in the FAQ). Some |
| 113 | versions of OpenSSH have a known problem with this: see |
| 114 | \k{faq-openssh-bad-openssl}. |
| 115 | |
| 116 | This can also happen in PSCP or PSFTP, if your login scripts on the |
| 117 | server generate output: the client program will be expecting an SFTP |
| 118 | message starting with a length, and if it receives some text from |
| 119 | your login scripts instead it will try to interpret them as a |
| 120 | message length. See \k{faq-outofmem2} for details of this. |
| 121 | |
| 122 | \H{errors-internal} \q{Internal error}, \q{Internal fault}, |
| 123 | \q{Assertion failed} |
| 124 | |
| 125 | Any error beginning with the word \q{Internal} should \e{never} |
| 126 | occur. If it does, there is a bug in PuTTY by definition; please see |
| 127 | \k{feedback} and report it to us. |
| 128 | |
| 129 | Similarly, any error message starting with \q{Assertion failed} is a |
| 130 | bug in PuTTY. Please report it to us, and include the exact text |
| 131 | from the error message box. |
| 132 | |
| 133 | \H{errors-key-wrong-format} \q{Unable to use this private key file}, |
| 134 | \q{Couldn't load private key}, \q{Key is of wrong type} |
| 135 | |
| 136 | Various forms of this error are printed in the PuTTY window, or |
| 137 | written to the PuTTY Event Log (see \k{using-eventlog}) when trying |
| 138 | public-key authentication, or given by Pageant when trying to load a |
| 139 | private key. |
| 140 | |
| 141 | If you see one of these messages, it often indicates that you've tried |
| 142 | to load a key of an inappropriate type into PuTTY, Plink, PSCP, PSFTP, |
| 143 | or Pageant. |
| 144 | |
| 145 | You may have specified a key that's inappropriate for the connection |
| 146 | you're making. The SSH-1 and SSH-2 protocols require different private |
| 147 | key formats, and a SSH-1 key can't be used for a SSH-2 connection (or |
| 148 | vice versa). |
| 149 | |
| 150 | Alternatively, you may have tried to load an SSH-2 key in a \q{foreign} |
| 151 | format (OpenSSH or \cw{ssh.com}) directly into one of the PuTTY tools, |
| 152 | in which case you need to import it into PuTTY's native format |
| 153 | (\c{*.PPK}) using PuTTYgen - see \k{puttygen-conversions}. |
| 154 | |
| 155 | \H{errors-refused} \q{Server refused our public key} or \q{Key |
| 156 | refused} |
| 157 | |
| 158 | Various forms of this error are printed in the PuTTY window, or |
| 159 | written to the PuTTY Event Log (see \k{using-eventlog}) when trying |
| 160 | public-key authentication. |
| 161 | |
| 162 | If you see one of these messages, it means that PuTTY has sent a |
| 163 | public key to the server and offered to authenticate with it, and |
| 164 | the server has refused to accept authentication. This usually means |
| 165 | that the server is not configured to accept this key to authenticate |
| 166 | this user. |
| 167 | |
| 168 | This is almost certainly not a problem with PuTTY. If you see this |
| 169 | type of message, the first thing you should do is check your |
| 170 | \e{server} configuration carefully. Common errors include having |
| 171 | the wrong permissions or ownership set on the public key or the |
| 172 | user's home directory on the server. Also, read the PuTTY Event Log; |
| 173 | the server may have sent diagnostic messages explaining exactly what |
| 174 | problem it had with your setup. |
| 175 | |
| 176 | \H{errors-access-denied} \q{Access denied}, \q{Authentication refused} |
| 177 | |
| 178 | Various forms of this error are printed in the PuTTY window, or |
| 179 | written to the PuTTY Event Log (see \k{using-eventlog}) during |
| 180 | authentication. |
| 181 | |
| 182 | If you see one of these messages, it means that the server has refused |
| 183 | all the forms of authentication PuTTY has tried and it has no further |
| 184 | ideas. |
| 185 | |
| 186 | It may be worth checking the Event Log for diagnostic messages from |
| 187 | the server giving more detail. |
| 188 | |
| 189 | This error can be caused by buggy SSH-1 servers that fail to cope with |
| 190 | the various strategies we use for camouflaging passwords in transit. |
| 191 | Upgrade your server, or use the workarounds described in |
| 192 | \k{config-ssh-bug-ignore1} and possibly \k{config-ssh-bug-plainpw1}. |
| 193 | |
| 194 | \H{errors-crc} \q{Incorrect CRC received on packet} or \q{Incorrect |
| 195 | MAC received on packet} |
| 196 | |
| 197 | This error occurs when PuTTY decrypts an SSH packet and its checksum |
| 198 | is not correct. This probably means something has gone wrong in the |
| 199 | encryption or decryption process. It's difficult to tell from this |
| 200 | error message whether the problem is in the client or in the server. |
| 201 | |
| 202 | A known server problem which can cause this error is described in |
| 203 | \k{faq-openssh-bad-openssl} in the FAQ. |
| 204 | |
| 205 | \H{errors-garbled} \q{Incoming packet was garbled on decryption} |
| 206 | |
| 207 | This error occurs when PuTTY decrypts an SSH packet and the |
| 208 | decrypted data makes no sense. This probably means something has |
| 209 | gone wrong in the encryption or decryption process. It's difficult |
| 210 | to tell from this error message whether the problem is in the client, |
| 211 | in the server, or in between. |
| 212 | |
| 213 | If you get this error, one thing you could try would be to fiddle |
| 214 | with the setting of \q{Miscomputes SSH2 encryption keys} on the Bugs |
| 215 | panel (see \k{config-ssh-bug-derivekey2}). |
| 216 | |
| 217 | Another known server problem which can cause this error is described |
| 218 | in \k{faq-openssh-bad-openssl} in the FAQ. |
| 219 | |
| 220 | \H{errors-x11-proxy} \q{PuTTY X11 proxy: \e{various errors}} |
| 221 | |
| 222 | This family of errors are reported when PuTTY is doing X forwarding. |
| 223 | They are sent back to the X application running on the SSH server, |
| 224 | which will usually report the error to the user. |
| 225 | |
| 226 | When PuTTY enables X forwarding (see \k{using-x-forwarding}) it |
| 227 | creates a virtual X display running on the SSH server. This display |
| 228 | requires authentication to connect to it (this is how PuTTY prevents |
| 229 | other users on your server machine from connecting through the PuTTY |
| 230 | proxy to your real X display). PuTTY also sends the server the |
| 231 | details it needs to enable clients to connect, and the server should |
| 232 | put this mechanism in place automatically, so your X applications |
| 233 | should just work. |
| 234 | |
| 235 | A common reason why people see one of these messages is because they |
| 236 | used SSH to log in as one user (let's say \q{fred}), and then used |
| 237 | the Unix \c{su} command to become another user (typically \q{root}). |
| 238 | The original user, \q{fred}, has access to the X authentication data |
| 239 | provided by the SSH server, and can run X applications which are |
| 240 | forwarded over the SSH connection. However, the second user |
| 241 | (\q{root}) does not automatically have the authentication data |
| 242 | passed on to it, so attempting to run an X application as that user |
| 243 | often fails with this error. |
| 244 | |
| 245 | If this happens, \e{it is not a problem with PuTTY}. You need to |
| 246 | arrange for your X authentication data to be passed from the user |
| 247 | you logged in as to the user you used \c{su} to become. How you do |
| 248 | this depends on your particular system; in fact many modern versions |
| 249 | of \c{su} do it automatically. |
| 250 | |
| 251 | \H{errors-connaborted} \q{Network error: Software caused connection |
| 252 | abort} |
| 253 | |
| 254 | This is a generic error produced by the Windows network code when it |
| 255 | kills an established connection for some reason. For example, it might |
| 256 | happen if you pull the network cable out of the back of an |
| 257 | Ethernet-connected computer, or if Windows has any other similar |
| 258 | reason to believe the entire network has become unreachable. |
| 259 | |
| 260 | We are not aware of any reason why this error might occur that would |
| 261 | represent a bug in PuTTY. The problem is between you, your Windows |
| 262 | system, your network and the remote system. |
| 263 | |
| 264 | Some people have reported that enabling keepalives (see |
| 265 | \k{config-keepalive}) fixes this error for them. |
| 266 | |
| 267 | \H{errors-connreset} \q{Network error: Connection reset by peer} |
| 268 | |
| 269 | This error occurs when the machines at each end of a network |
| 270 | connection lose track of the state of the connection between them. |
| 271 | For example, you might see it if your SSH server crashes, and |
| 272 | manages to reboot fully before you next attempt to send data to it. |
| 273 | |
| 274 | However, the most common reason to see this message is if you are |
| 275 | connecting through a firewall or a NAT router which has timed the |
| 276 | connection out. See \k{faq-idleout} in the FAQ for more details. You |
| 277 | may be able to improve the situation by using keepalives; see |
| 278 | \k{config-keepalive} for details on this. |
| 279 | |
| 280 | Note that Windows can produce this error in some circumstances without |
| 281 | seeing a connection reset from the server, for instance if the |
| 282 | connection to the network is lost. |
| 283 | |
| 284 | \H{errors-connrefused} \q{Network error: Connection refused} |
| 285 | |
| 286 | This error means that the network connection PuTTY tried to make to |
| 287 | your server was rejected by the server. Usually this happens because |
| 288 | the server does not provide the service which PuTTY is trying to |
| 289 | access. |
| 290 | |
| 291 | Check that you are connecting with the correct protocol (SSH, Telnet |
| 292 | or Rlogin), and check that the port number is correct. If that |
| 293 | fails, consult the administrator of your server. |
| 294 | |
| 295 | \H{errors-conntimedout} \q{Network error: Connection timed out} |
| 296 | |
| 297 | This error means that the network connection PuTTY tried to make to |
| 298 | your server received no response at all from the server. Usually |
| 299 | this happens because the server machine is completely isolated from |
| 300 | the network, or because it is turned off. |
| 301 | |
| 302 | Check that you have correctly entered the host name or IP address of |
| 303 | your server machine. If that fails, consult the administrator of |
| 304 | your server. |