New option to reject 'trivial' success of userauth.

Suggested by Manfred Kaiser, who also wrote most of this patch
(although outlying parts, like documentation and SSH-1 support, are by
me).

This is a second line of defence against the kind of spoofing attacks
in which a malicious or compromised SSH server rushes the client
through the userauth phase of SSH without actually requiring any auth
inputs (passwords or signatures or whatever), and then at the start of
the connection phase it presents something like a spoof prompt,
intended to be taken for part of userauth by the user but in fact with
some more sinister purpose.

Our existing line of defence against this is the trust sigil system,
and as far as I know, that's still working. This option allows a bit of
extra defence in depth: if you don't expect your SSH server to
trivially accept authentication in the first place, then enabling this
option will cause PuTTY to disconnect if it unexpectedly does so,
without the user having to spot the presence or absence of a fiddly
little sigil anywhere.

Several types of authentication count as 'trivial'. The obvious one is
the SSH-2 "none" method, which clients always try first so that the
failure message will tell them what else they can try, and which a
server can instead accept in order to authenticate you unconditionally.
But there are two other ways to do it that we know of: one is to run
keyboard-interactive authentication and send an empty INFO_REQUEST
packet containing no actual prompts for the user, and another even
weirder one is to send USERAUTH_SUCCESS in response to the user's
preliminary *offer* of a public key (instead of sending the usual PK_OK
to request an actual signature from the key).

This new option detects all of those, by clearing the 'is_trivial_auth'
flag only when we send some kind of substantive authentication response
(be it a password, a k-i prompt response, a signature, or a GSSAPI
token). So even if there's a further path through the userauth maze we
haven't spotted, that somehow avoids sending anything substantive, this
strategy should still pick it up.

(cherry picked from commit 5f5c710cf3)

doc/config.but

@@ -2623,6 +2623,49 @@ interact with them.)
 This option only affects SSH-2 connections. SSH-1 connections always
 require an authentication step.
 
+\S{config-ssh-notrivialauth} \q{Disconnect if authentication succeeds
+trivially}
+
+This option causes PuTTY to abandon an SSH session and disconnect from
+the server, if the server accepted authentication without ever having
+asked for any kind of password or signature or token.
+
+This might be used as a security measure. There are some forms of
+attack against an SSH client user which work by terminating the SSH
+authentication stage early, and then doing something in the main part
+of the SSH session which \e{looks} like part of the authentication,
+but isn't really.
+
+For example, instead of demanding a signature from your public key,
+for which PuTTY would ask for your key's passphrase, a compromised or
+malicious server might allow you to log in with no signature or
+password at all, and then print a message that \e{imitates} PuTTY's
+request for your passphrase, in the hope that you would type it in.
+(In fact, the passphrase for your public key should not be sent to any
+server.)
+
+PuTTY's main defence against attacks of this type is the \q{trust
+sigil} system: messages in the PuTTY window that are truly originated
+by PuTTY itself are shown next to a small copy of the PuTTY icon,
+which the server cannot fake when it tries to imitate the same message
+using terminal output.
+
+However, if you think you might be at risk of this kind of thing
+anyway (if you don't watch closely for the trust sigils, or if you
+think you're at extra risk of one of your servers being malicious),
+then you could enable this option as an extra defence. Then, if the
+server tries any of these attacks involving letting you through the
+authentication stage, PuTTY will disconnect from the server before it
+can send a follow-up fake prompt or other type of attack.
+
+On the other hand, some servers \e{legitimately} let you through the
+SSH authentication phase trivially, either because they are genuinely
+public, or because the important authentication step happens during
+the terminal session. (An example might be an SSH server that connects
+you directly to the terminal login prompt of a legacy mainframe.) So
+enabling this option might cause some kinds of session to stop
+working. It's up to you.
+
 \S{config-ssh-tryagent} \q{Attempt authentication using Pageant}
 
 If this option is enabled, then PuTTY will look for Pageant (the SSH