More sensible error handling when we receive an SSH1 public key
[u/mdw/putty] / doc / errors.but
index 211e71f..4b9496d 100644 (file)
@@ -1,4 +1,4 @@
-\versionid $Id: errors.but,v 1.7 2003/07/12 13:25:43 jacob Exp $
+\versionid $Id: errors.but,v 1.9 2004/07/22 12:38:37 jacob Exp $
 
 \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.
 
+\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}
 
@@ -188,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.
 
-\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
@@ -203,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.
 
-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