+\S{faq-password-fails}{Question} My keyboard stops working once
+PuTTY displays the password prompt.
+
+No, it doesn't. PuTTY just doesn't display the password you type, so
+that someone looking at your screen can't see what it is.
+
+Unlike the Windows login prompts, PuTTY doesn't display the password
+as a row of asterisks either. This is so that someone looking at
+your screen can't even tell how \e{long} your password is, which
+might be valuable information.
+
+\S{faq-keyboard}{Question} One or more function keys don't do what I
+expected in a server-side application.
+
+If you've already tried all the relevant options in the PuTTY
+Keyboard panel, you may need to mail the PuTTY maintainers and ask.
+
+It is \e{not} usually helpful just to tell us which application,
+which server operating system, and which key isn't working; in order
+to replicate the problem we would need to have a copy of every
+operating system, and every application, that anyone has ever
+complained about.
+
+PuTTY responds to function key presses by sending a sequence of
+control characters to the server. If a function key isn't doing what
+you expect, it's likely that the character sequence your application
+is expecting to receive is not the same as the one PuTTY is sending.
+Therefore what we really need to know is \e{what} sequence the
+application is expecting.
+
+The simplest way to investigate this is to find some other terminal
+environment, in which that function key \e{does} work; and then
+investigate what sequence the function key is sending in that
+situation. One reasonably easy way to do this on a Unix system is to
+type the command \c{cat}, and then press the function key. This is
+likely to produce output of the form \c{^[[11~}. You can also do
+this in PuTTY, to find out what sequence the function key is
+producing in that. Then you can mail the PuTTY maintainers and tell
+us \q{I wanted the F1 key to send \c{^[[11~}, but instead it's
+sending \c{^[OP}, can this be done?}, or something similar.
+
+You should still read the
+\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/feedback.html}{Feedback
+page} on the PuTTY website (also provided as \k{feedback} in the
+manual), and follow the guidelines contained in that.
+
+\S{faq-openssh-bad-openssl}{Question} Since my SSH server was upgraded
+to \i{OpenSSH} 3.1p1/3.4p1, I can no longer connect with PuTTY.
+
+There is a known problem when OpenSSH has been built against an
+incorrect version of OpenSSL; the quick workaround is to configure
+PuTTY to use SSH protocol 2 and the Blowfish cipher.
+
+For more details and OpenSSH patches, see
+\W{http://bugzilla.mindrot.org/show_bug.cgi?id=138}{bug 138} in the
+OpenSSH BTS.
+
+This is not a PuTTY-specific problem; if you try to connect with
+another client you'll likely have similar problems. (Although PuTTY's
+default cipher differs from many other clients.)
+
+\e{OpenSSH 3.1p1:} configurations known to be broken (and symptoms):
+
+\b SSH-2 with AES cipher (PuTTY says \q{Assertion failed! Expression:
+(len & 15) == 0} in \cw{sshaes.c}, or \q{Out of memory}, or crashes)
+
+\b SSH-2 with 3DES (PuTTY says \q{Incorrect MAC received on packet})
+
+\b SSH-1 with Blowfish (PuTTY says \q{Incorrect CRC received on
+packet})
+
+\b SSH-1 with 3DES
+
+\e{OpenSSH 3.4p1:} as of 3.4p1, only the problem with SSH-1 and
+Blowfish remains. Rebuild your server, apply the patch linked to from
+bug 138 above, or use another cipher (e.g., 3DES) instead.
+
+\e{Other versions:} we occasionally get reports of the same symptom
+and workarounds with older versions of OpenSSH, although it's not
+clear the underlying cause is the same.
+
+\S{faq-ssh2key-ssh1conn}{Question} Why do I see \q{Couldn't load
+private key from ...}? Why can PuTTYgen load my key but not PuTTY?
+
+It's likely that you've generated an SSH protocol 2 key with PuTTYgen,
+but you're trying to use it in an SSH-1 connection. SSH-1 and SSH-2 keys
+have different formats, and (at least in 0.52) PuTTY's reporting of a
+key in the wrong format isn't optimal.
+
+To connect using SSH-2 to a server that supports both versions, you
+need to change the configuration from the default (see \k{faq-ssh2}).
+
+\S{faq-rh8-utf8}{Question} When I'm connected to a \i{Red Hat Linux} 8.0
+system, some characters don't display properly.
+
+A common complaint is that hyphens in man pages show up as a-acute.
+
+With release 8.0, Red Hat appear to have made \i{UTF-8} the default
+character set. There appears to be no way for terminal emulators such
+as PuTTY to know this (as far as we know, the appropriate escape
+sequence to switch into UTF-8 mode isn't sent).
+
+A fix is to configure sessions to RH8 systems to use UTF-8
+translation - see \k{config-charset} in the documentation. (Note that
+if you use \q{Change Settings}, changes may not take place immediately
+- see \k{faq-resetterm}.)
+
+If you really want to change the character set used by the server, the
+right place is \c{/etc/sysconfig/i18n}, but this shouldn't be
+necessary.
+
+\S{faq-screen}{Question} Since I upgraded to PuTTY 0.54, the
+scrollback has stopped working when I run \c{screen}.
+
+PuTTY's terminal emulator has always had the policy that when the
+\q{\i{alternate screen}} is in use, nothing is added to the scrollback.
+This is because the usual sorts of programs which use the alternate
+screen are things like text editors, which tend to scroll back and
+forth in the same document a lot; so (a) they would fill up the
+scrollback with a large amount of unhelpfully disordered text, and
+(b) they contain their \e{own} method for the user to scroll back to
+the bit they were interested in. We have generally found this policy
+to do the Right Thing in almost all situations.
+
+Unfortunately, \c{screen} is one exception: it uses the alternate
+screen, but it's still usually helpful to have PuTTY's scrollback
+continue working. The simplest solution is to go to the Features
+control panel and tick \q{Disable switching to alternate terminal
+screen}. (See \k{config-features-altscreen} for more details.)
+Alternatively, you can tell \c{screen} itself not to use the
+alternate screen: the
+\W{http://www4.informatik.uni-erlangen.de/~jnweiger/screen-faq.html}{\c{screen}
+FAQ} suggests adding the line \cq{termcapinfo xterm ti@:te@} to your
+\cw{.screenrc} file.
+
+The reason why this only started to be a problem in 0.54 is because
+\c{screen} typically uses an unusual control sequence to switch to
+the alternate screen, and previous versions of PuTTY did not support
+this sequence.
+
+\S{faq-alternate-localhost}{Question} Since I upgraded \i{Windows XP}
+to Service Pack 2, I can't use addresses like \cw{127.0.0.2}.
+
+Some people who ask PuTTY to listen on \i{localhost} addresses other
+than \cw{127.0.0.1} to forward services such as \i{SMB} and \i{Windows
+Terminal Services} have found that doing so no longer works since
+they upgraded to WinXP SP2.
+
+This is apparently an issue with SP2 that is acknowledged by Microsoft
+in MS Knowledge Base article
+\W{http://support.microsoft.com/default.aspx?scid=kb;en-us;884020}{884020}.
+The article links to a fix you can download.
+
+(\e{However}, we've been told that SP2 \e{also} fixes the bug that
+means you need to use non-\cw{127.0.0.1} addresses to forward
+Terminal Services in the first place.)
+
+\S{faq-missing-slash}{Question} PSFTP commands seem to be missing a
+directory separator (slash).
+
+Some people have reported the following incorrect behaviour with
+PSFTP:
+
+\c psftp> pwd
+\e iii
+\c Remote directory is /dir1/dir2
+\c psftp> get filename.ext
+\e iiiiiiiiiiiiiiii
+\c /dir1/dir2filename.ext: no such file or directory
+
+This is not a bug in PSFTP. There is a known bug in some versions of
+portable \i{OpenSSH}
+(\W{http://bugzilla.mindrot.org/show_bug.cgi?id=697}{bug 697}) that
+causes these symptoms; it appears to have been introduced around
+3.7.x. It manifests only on certain platforms (AIX is what has been
+reported to us).
+
+There is a patch for OpenSSH attached to that bug; it's also fixed in
+recent versions of portable OpenSSH (from around 3.8).
+
+\S{faq-connaborted}{Question} Do you want to hear about \q{Software
+caused connection abort}?
+
+In the documentation for PuTTY 0.53 and 0.53b, we mentioned that we'd
+like to hear about any occurrences of this error. Since the release
+of PuTTY 0.54, however, we've been convinced that this error doesn't
+indicate that PuTTY's doing anything wrong, and we don't need to hear
+about further occurrences. See \k{errors-connaborted} for our current
+documentation of this error.
+
+\S{faq-rekey}{Question} My SSH-2 session \I{locking up, SSH-2
+sessions}locks up for a few seconds every so often.
+
+Recent versions of PuTTY automatically initiate \i{repeat key
+exchange} once per hour, to improve session security. If your client
+or server machine is slow, you may experience this as a delay of
+anything up to thirty seconds or so.
+
+These \I{delays, in SSH-2 sessions}delays are inconvenient, but they
+are there for your protection. If they really cause you a problem,
+you can choose to turn off periodic rekeying using the \q{Kex}
+configuration panel (see \k{config-ssh-kex}), but be aware that you
+will be sacrificing security for this. (Falling back to SSH-1 would
+also remove the delays, but would lose a \e{lot} more security
+still. We do not recommend it.)
+