Add a section on the errors you see when you attempt to load a key of the

[u/mdw/putty] / doc / errors.but

diff --git a/doc/errors.but b/doc/errors.but
index 51ecd37..4b9496d 100644 (file)
--- a/doc/errors.but
+++ b/doc/errors.but
@@ -1,4 +1,4 @@
-\versionid $Id: errors.but,v 1.6 2003/03/18 09:03:31 simon Exp $
+\versionid $Id: errors.but,v 1.9 2004/07/22 12:38:37 jacob Exp $

 
 \C{errors} Common error messages
 
 
 \C{errors} Common error messages
 


@@ -125,6 +125,28 @@ 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.
 
 bug in PuTTY. Please report it to us, and include the exact text
 from the error message box.
 

+\H{errors-key-wrong-format} \q{Unable to use this private key file},
+\q{Couldn't load private key}, \q{Key is of wrong type}
+
+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}
 
 \H{errors-refused} \q{Server refused our public key} or \q{Key
 refused}
 


@@ -144,6 +166,24 @@ type of message, the first thing you should do is check your
 the server may have sent diagnostic messages explaining exactly what
 problem it had with your setup.
 
 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}
 
 \H{errors-crc} \q{Incorrect CRC received on packet} or \q{Incorrect
 MAC received on packet}
 


@@ -170,11 +210,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.
 
 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
 
 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 +225,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.
 
 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
 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