\k{pubkey} in the documentation for a full discussion of public key
authentication.
+\S{faq-hostkeys} Is there an option to turn off the annoying host
+key prompts?
+
+No, there isn't. And there won't be. Even if you write it yourself
+and send us the patch, we won't accept it.
+
+Those annoying host key prompts are the \e{whole point} of SSH.
+Without them, all the cryptographic technology SSH uses to secure
+your session is doing nothing more than making an attacker's job
+slightly harder; instead of sitting between you and the server with
+a packet sniffer, the attacker must actually subvert a router and
+start modifying the packets going back and forth. But that's not all
+that much harder than just sniffing; and without host key checking,
+it will go completely undetected by client or server.
+
+Host key checking is your guarantee that the encryption you put on
+your data at the client end is the \e{same} encryption taken off the
+data at the server end; it's your guarantee that it hasn't been
+removed and replaced somewhere on the way. Host key checking makes
+the attacker's job \e{astronomically} hard, compared to packet
+sniffing, and even compared to subverting a router. Instead of
+applying a little intelligence and keeping an eye on Bugtraq, the
+attacker must now perform a brute-force attack against at least one
+military-strength cipher. That insignificant host key prompt really
+does make \e{that} much difference.
+
+If you're having a specific problem with host key checking - perhaps
+you want an automated batch job to make use of PSCP or Plink, and
+the interactive host key prompt is hanging the batch process - then
+the right way to fix it is to add the correct host key to the
+Registry in advance. That way, you retain the \e{important} feature
+of host key checking: the right key will be accepted and the wrong
+ones will not. Adding an option to turn host key checking off
+completely is the wrong solution and we will not do it.
+
+\S{faq-server} Will you write an SSH server for the PuTTY suite, to
+go with the client?
+
+No. The only reason we might want to would be if we could easily
+re-use existing code and significantly cut down the effort. We don't
+believe this is the case; there just isn't enough common ground
+between an SSH client and server to make it worthwhile.
+
+If someone else wants to use bits of PuTTY in the process of writing
+a Windows SSH server, they'd be perfectly welcome to of course, but
+I really can't see it being a lot less effort for us to do that than
+it would be for us to write a server from the ground up. We don't
+have time, and we don't have motivation. The code is available if
+anyone else wants to try it.
+
\H{faq-ports} Ports to other operating systems
The eventual goal is for PuTTY to be a multi-platform program, able
You can also paste by pressing Shift-Ins.
+\S{faq-tunnels} How do I use X forwarding and port forwarding? I
+can't find the Tunnels panel.
+
+If you're looking in the 0.51 release or earlier, the Tunnels panel
+isn't there. It was added in the development snapshots after 0.51,
+and releases 0.52 and onwards will contain it.
+
+\S{faq-options} How do I use all PuTTY's features (public keys, port
+forwarding, SSH v2, etc.) in PSCP, PSFTP and Plink?
+
+The command-line tools are currently rather short of command line
+options to enable this sort of thing. However, you can use most of
+PuTTY's features if you create a PuTTY saved session, and then use
+the name of the saved session on the command line in place of a
+hostname. This works for PSCP, PSFTP and Plink (but don't expect
+port forwarding in the file transfer applications!).
+
\S{faq-pscp} How do I use PSCP.EXE? When I double-click it gives me
a command prompt window which then closes instantly.
server instead); but it doesn't necessarily mean you've actually run
out of memory.
+\S{faq-bce} When I run full-colour applications, I see areas of
+black space where colour ought to be.
+
+You almost certainly need to enable the \q{Use background colour to
+erase screen} setting in the Terminal panel. Note that if you do
+this in mid-session, it won't take effect until you reset the
+terminal (see \k{faq-resetterm}).
+
+\S{faq-resetterm} When I change some terminal settings, nothing
+happens.
+
+Some of the terminal options (notably Auto Wrap and
+background-colour screen erase) actually represent the \e{default}
+setting, rather than the currently active setting. The server can
+send sequences that modify these options in mid-session, but when
+the terminal is reset (by server action, or by you choosing \q{Reset
+Terminal} from the System menu) the defaults are restored.
+
+If you want to change one of these options in the middle of a
+session, you will find that the change does not immediately take
+effect. It will only take effect once you reset the terminal.
+
\S{faq-altgr} I can't type characters that require the AltGr key.
In PuTTY version 0.51, the AltGr key was broken. The bug has been
accident, and cause unexpected changes in the window title. Don't do
it.
+\S{faq-password} 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.
+
\H{faq-secure} Security questions
\S{faq-publicpc} Is it safe for me to download PuTTY and use it on a
~mdw / sgt / putty / blobdiff