Add context help to a couple of message boxes. Unfortunately the ones
[sgt/putty] / doc / errors.but
index 51786b9..2c4385e 100644 (file)
@@ -1,4 +1,4 @@
-\versionid $Id: errors.but,v 1.4 2003/01/31 23:18:44 ben Exp $
+\define{versioniderrors} \versionid $Id$
 
 \C{errors} Common error messages
 
@@ -15,6 +15,8 @@ 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
@@ -36,6 +38,8 @@ 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
@@ -69,7 +73,8 @@ this, let us know and we'll move it up our priority list.
 ... 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.
+have configured PuTTY to consider strong enough. By default, PuTTY
+puts up this warning only for single-DES encryption.
 
 See \k{config-ssh-encryption} for more information on this message.
 
@@ -125,6 +130,30 @@ 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}
 
@@ -140,10 +169,30 @@ this user.
 
 This is almost certainly not a problem with PuTTY. If you see this
 type of message, the first thing you should do is check your
-\e{server} configuration carefully. Also, read the PuTTY Event Log;
+\e{server} configuration carefully. Common errors include having
+the wrong permissions or ownership set on the public key or the
+user's home directory on the server. Also, read the PuTTY Event Log;
 the server may have sent diagnostic messages explaining exactly what
 problem it had with your setup.
 
+\H{errors-access-denied} \q{Access denied}, \q{Authentication refused}
+
+Various forms of this error are printed in the PuTTY window, or
+written to the PuTTY Event Log (see \k{using-eventlog}) during
+authentication.
+
+If you see one of these messages, it means that the server has refused 
+all the forms of authentication PuTTY has tried and it has no further
+ideas.
+
+It may be worth checking the Event Log for diagnostic messages from
+the server giving more detail.
+
+This error can be caused by buggy SSH-1 servers that fail to cope with
+the various strategies we use for camouflaging passwords in transit.
+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}
 
@@ -160,8 +209,8 @@ A known server problem which can cause this error is described in
 This error occurs when PuTTY decrypts an SSH packet and the
 decrypted data makes no sense. This probably means something has
 gone wrong in the encryption or decryption process. It's difficult
-to tell from this error message whether the problem is in the client
-or in the server.
+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 SSH2 encryption keys} on the Bugs
@@ -170,11 +219,11 @@ panel (see \k{config-ssh-bug-derivekey2}).
 Another known server problem which can cause this error is described
 in \k{faq-openssh-bad-openssl} in the FAQ.
 
-\H{errors-x11-proxy} \q{Authentication failed at PuTTY X11 proxy}
+\H{errors-x11-proxy} \q{PuTTY X11 proxy: \e{various errors}}
 
-This error is reported when PuTTY is doing X forwarding. It is sent
-back to the X application running on the SSH server, which will
-usually report the error to the user.
+This family of errors are reported when PuTTY is doing X forwarding.
+They are sent back to the X application running on the SSH server,
+which will usually report the error to the user.
 
 When PuTTY enables X forwarding (see \k{using-x-forwarding}) it
 creates a virtual X display running on the SSH server. This display
@@ -185,10 +234,10 @@ details it needs to enable clients to connect, and the server should
 put this mechanism in place automatically, so your X applications
 should just work.
 
-A common reason why people see this message is because they used SSH
-to log in as one user (let's say \q{fred}), and then used the Unix
-\c{su} command to become another user (typically \q{root}). The
-original user, \q{fred}, has access to the X authentication data
+A common reason why people see one of these messages is because they
+used SSH to log in as one user (let's say \q{fred}), and then used
+the Unix \c{su} command to become another user (typically \q{root}).
+The original user, \q{fred}, has access to the X authentication data
 provided by the SSH server, and can run X applications which are
 forwarded over the SSH connection. However, the second user
 (\q{root}) does not automatically have the authentication data
@@ -204,20 +253,18 @@ of \c{su} do it automatically.
 \H{errors-connaborted} \q{Network error: Software caused connection
 abort}
 
-In modern versions of PuTTY, you should not see this error.
-
-Windows's documentation about this error condition is not very good,
-but as far as we can tell, this error occurs when PuTTY is listening
-on a port, another program makes a connection to that port, but
-closes the connection so fast that PuTTY has no time to answer it.
+This is a generic error produced by the Windows network code when it
+kills an established connection for some reason. For example, it might
+happen if you pull the network cable out of the back of an
+Ethernet-connected computer, or if Windows has any other similar
+reason to believe the entire network has become unreachable.
 
-PuTTY only ever listens on a port when it is doing local-to-remote
-port forwarding (see \k{using-port-forwarding}); and if an incoming
-connection on that port receives this error, PuTTY should simply
-close the connection and continue without error.
+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.
 
-If you see this error in PuTTY 0.53 or above, we would welcome a
-report of the circumstances.
+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}
 
@@ -232,6 +279,10 @@ 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.
 
+Note that Windows can produce this error in some circumstances without
+seeing a connection reset from the server, for instance if the
+connection to the network is lost.
+
 \H{errors-connrefused} \q{Network error: Connection refused}
 
 This error means that the network connection PuTTY tried to make to
@@ -242,3 +293,14 @@ access.
 Check that you are connecting with the correct protocol (SSH, Telnet
 or Rlogin), and check that the port number is correct. If that
 fails, consult the administrator of your server.
+
+\H{errors-conntimedout} \q{Network error: Connection timed out}
+
+This error means that the network connection PuTTY tried to make to
+your server received no response at all from the server. Usually
+this happens because the server machine is completely isolated from
+the network, or because it is turned off.
+
+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.