errors.but

putty

\define{versioniderrors} \versionid $Id: errors.but 6461 2005-11-14 09:41:42Z jacob $

\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
more detail.

We do not attempt to list \e{all} error messages here: there are
many which should never occur, and some which should be
self-explanatory. If you get an error message which is not listed in
this chapter and which you don't understand, report it to us as a
bug (see \k{feedback}) and we will add documentation for it.

\H{errors-hostkey-absent} \q{The server's host key is not cached in
the registry}

\cfg{winhelp-topic}{errors.hostkey.absent}

This error message occurs when PuTTY connects to a new SSH server.
Every server identifies itself by means of a host key; once PuTTY
knows the host key for a server, it will be able to detect if a
malicious attacker redirects your connection to another machine.

If you see this message, it means that PuTTY has not seen this host
key before, and has no way of knowing whether it is correct or not.
You should attempt to verify the host key by other means, such as
asking the machine's administrator.

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 \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-hostkey-wrong} \q{WARNING - POTENTIAL SECURITY BREACH!}

\cfg{winhelp-topic}{errors.hostkey.changed}

This message, followed by \q{The server's host key does not match
the one PuTTY has cached in the registry}, means that PuTTY has
connected to the SSH server before, knows what its host key
\e{should} be, but has found a different one.

This may mean that a malicious attacker has replaced your server
with a different one, or has redirected your network connection to
their own machine. On the other hand, it may simply mean that the
administrator of your server has accidentally changed the key while
upgrading the SSH software; this \e{shouldn't} happen but it is
unfortunately possible.

You should contact your server's administrator and see whether they
expect the host key to have changed. If so, verify the new host key
in the same way as you would if it was new.

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 \i{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 \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
(protocol error): "Too many authentication failures for root"}

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, 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.

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
computer really has run out of memory, or if you have configured an
extremely large number of lines of scrollback in your terminal.
PuTTY is not able to recover from running out of memory; it will
terminate immediately after giving this error.

However, this error can also occur when memory is not running out at
all, because PuTTY receives data in the wrong format. In SSH-2 and
also in SFTP, the server sends the length of each message before the
message itself; so PuTTY will receive the length, try to allocate
space for the message, and then receive the rest of the message. If
the length PuTTY receives is garbage, it will try to allocate a
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}.

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{\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
\k{feedback} and report it to us.

Similarly, any error message starting with \q{Assertion failed} is a
bug in PuTTY. Please report it to us, and include the exact text
from the error message box.

\H{errors-cant-load-key} \q{Unable to use this private key file},
\q{Couldn't load private key}, \q{Key is of wrong type}

\cfg{winhelp-topic}{errors.cantloadkey}

Various forms of this error are printed in the PuTTY window, or
written to the PuTTY Event Log (see \k{using-eventlog}) when trying
public-key authentication, or given by Pageant when trying to load a
private key.

If you see one of these messages, it often indicates that you've tried
to load a key of an inappropriate type into PuTTY, Plink, PSCP, PSFTP,
or Pageant.

You may have specified a key that's inappropriate for the connection
you're making. The SSH-1 and SSH-2 protocols require different private
key formats, and a SSH-1 key can't be used for a SSH-2 connection (or
vice versa).

Alternatively, you may have tried to load an SSH-2 key in a \q{foreign}
format (OpenSSH or \cw{ssh.com}) directly into one of the PuTTY tools,
in which case you need to import it into PuTTY's native format
(\c{*.PPK}) using PuTTYgen - see \k{puttygen-conversions}.

\H{errors-refused} \q{Server refused our public key} or \q{Key
refused}

Various forms of this error are printed in the PuTTY window, or
written to the PuTTY Event Log (see \k{using-eventlog}) when trying