Fiddle with the cmdline_saved mechanism: the `-load' option is now

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

\versionid $Id: faq.but,v 1.45 2003/03/04 14:14:17 ben Exp $

\A{faq} PuTTY FAQ

This FAQ is published on the PuTTY web site, and also provided as an
appendix in the manual.

\H{faq-support} Features supported in PuTTY

In general, if you want to know if PuTTY supports a particular
feature, you should look for it on the
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/}{PuTTY web site}.
In particular:

\b try the
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html}{changes
page}, and see if you can find the feature on there. If a feature is
listed there, it's been implemented. If it's listed as a change made
\e{since} the latest version, it should be available in the
development snapshots, in which case testing will be very welcome.

\b try the
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/}{Wishlist
page}, and see if you can find the feature there. If it's on there,
and not in the \q{Recently fixed} section, it probably \e{hasn't} been
implemented.

\S{faq-ssh2}{Question} Does PuTTY support SSH v2?

Yes. SSH v2 support has been available in PuTTY since version 0.50.
However, currently the \e{default} SSH protocol is v1; to select SSH
v2 if your server supports both, go to the SSH panel and change the
\e{Preferred SSH protocol version} option. (The factory default will
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/ssh2-default.html}{change to v2}
in the next full release.)

Public key authentication (both RSA and DSA) in SSH v2 is new in
version 0.52.

\S{faq-ssh2-keyfmt}{Question} Does PuTTY support reading OpenSSH or
\cw{ssh.com} SSHv2 private key files?

PuTTY doesn't support this natively, but as of 0.53
PuTTYgen can convert both OpenSSH and \cw{ssh.com} private key
files into PuTTY's format.

\S{faq-ssh1}{Question} Does PuTTY support SSH v1?

Yes. SSH 1 support has always been available in PuTTY.

\S{faq-localecho}{Question} Does PuTTY support local echo?

Yes. Version 0.52 has proper support for local echo.

In version 0.51 and before, local echo could not be separated from
local line editing (where you type a line of text locally, and it is
not sent to the server until you press Return, so you have the
chance to edit it and correct mistakes \e{before} the server sees
it). New in version 0.52, local echo and local line editing are
separate options, and by default PuTTY will try to determine
automatically whether to enable them or not, based on which protocol
you have selected and also based on hints from the server. If you
have a problem with PuTTY's default choice, you can force each
option to be enabled or disabled as you choose. The controls are in
the Terminal panel, in the section marked \q{Line discipline
options}.

\S{faq-disksettings}{Question} Does PuTTY support storing its
settings in a disk file?

Not at present, although \k{config-file} in the documentation gives
a method of achieving the same effect.

\S{faq-fullscreen}{Question} Does PuTTY support full-screen mode,
like a DOS box?

Yes; this is a new feature in version 0.52.

\S{faq-password-remember}{Question} Does PuTTY have the ability to
remember my password so I don't have to type it every time?

No, it doesn't.

Remembering your password is a bad plan for obvious security
reasons: anyone who gains access to your machine while you're away
from your desk can find out the remembered password, and use it,
abuse it or change it.

In addition, it's not even \e{possible} for PuTTY to automatically
send your password in a Telnet session, because Telnet doesn't give
the client software any indication of which part of the login
process is the password prompt. PuTTY would have to guess, by
looking for words like \q{password} in the session data; and if your
login program is written in something other than English, this won't
work.

In SSH, remembering your password would be possible in theory, but
there doesn't seem to be much point since SSH supports public key
authentication, which is more flexible and more secure. See
\k{pubkey} in the documentation for a full discussion of public key
authentication.

\S{faq-hostkeys}{Question} 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}{Question} 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.

\S{faq-pscp-ascii}{Question} Can PSCP or PSFTP transfer files in
ASCII mode?

Unfortunately not. This is a limitation of the file transfer
protocols: the SCP and SFTP protocols have no notion of transferring
a file in anything other than binary mode.

SFTP is designed to be extensible, so it's possible that an
extension might be proposed at some later date that implements ASCII
transfer. But the PuTTY team can't do anything about it until that
happens.

\H{faq-ports} Ports to other operating systems

The eventual goal is for PuTTY to be a multi-platform program, able
to run on at least Windows, Mac OS and Unix.

Porting will become easier once PuTTY has a generalised porting
layer, drawing a clear line between platform-dependent and
platform-independent code. The general intention was for this
porting layer to evolve naturally as part of the process of doing
the first port; a Unix port is now under way and the plan seems to
be working so far.

\S{faq-ports-general}{Question} What ports of PuTTY exist?

Currently, release versions of PuTTY only run on full Win32 systems.
This includes Windows 95, 98, and ME, and it includes Windows NT,
Windows 2000 and Windows XP. In the development code, partial ports
to Unix (see \k{faq-unix}) and the Mac OS (see \k{faq-mac-port}).
are under way.

Currently PuTTY does \e{not} run on Windows CE (see \k{faq-wince}),
and it does not quite run on the Win32s environment under Windows
3.1 (see \k{faq-win31}).

We do not have release-quality ports for any other systems at the
present time. If anyone told you we had a Mac port, or an iPaq port,
or any other port of PuTTY, they were mistaken. We don't.

\S{faq-unix}{Question} Will there be a port to Unix?

It's currently being worked on. If you look at the nightly source
snapshots, you should find a \c{unix} subdirectory, which should
build you a Unix port of Plink, and also \c{pterm} - an
\cw{xterm}-type program which supports the same terminal emulation
as PuTTY.

It isn't yet clear whether we will bother combining the terminal
emulator and network back end into the same process, to provide a
Unix port of the full GUI form of PuTTY. It wouldn't be as useful a
thing on Unix as it would be on Windows; its major value would
probably be as a pathfinding effort for other ports. If anyone
really wants it, we'd be interested to know why :-)

\S{faq-wince}{Question} Will there be a port to Windows CE or PocketPC?

Probably not in the particularly near future. Despite sharing large
parts of the Windows API, in practice WinCE doesn't appear to be
significantly easier to port to than a totally different operating
system.

However, PuTTY on portable devices would clearly be a useful thing,
so in the long term I hope there will be a WinCE port.

\S{faq-win31}{Question} Is there a port to Windows 3.1?

PuTTY is a 32-bit application from the ground up, so it won't run on
Windows 3.1 as a native 16-bit program; and it would be \e{very}
hard to port it to do so, because of Windows 3.1's vile memory
allocation mechanisms.

However, it is possible in theory to compile the existing PuTTY
source in such a way that it will run under Win32s (an extension to
Windows 3.1 to let you run 32-bit programs). In order to do this
you'll need the right kind of C compiler - modern versions of Visual
C at least have stopped being backwards compatible to Win32s. Also,
the last time we tried this it didn't work very well.

If you're interested in running PuTTY under Windows 3.1, help and
testing in this area would be very welcome!

\S{faq-mac-port}{Question} Will there be a port to the Mac?

Eventually.  The terminal emulation code has been ported, as has the
saved-settings infrastructure, but networking and a configuration GUI
still need to be done before the port will be of any use.

\S{faq-epoc}{Question} Will there be a port to EPOC?

I hope so, but given that ports aren't really progressing very fast
even on systems the developers \e{do} already know how to program
for, it might be a long time before any of us get round to learning
a new system and doing the port for that.

\H{faq-embedding} Embedding PuTTY in other programs

\S{faq-dll}{Question} Is the SSH or Telnet code available as a DLL?

No, it isn't. It would take a reasonable amount of rewriting for
this to be possible, and since the PuTTY project itself doesn't
believe in DLLs (they make installation more error-prone) none of us
has taken the time to do it.

Most of the code cleanup work would be a good thing to happen in
general, so if anyone feels like helping, we wouldn't say no.

\S{faq-vb}{Question} Is the SSH or Telnet code available as a Visual
Basic component?

No, it isn't. None of the PuTTY team uses Visual Basic, and none of
us has any particular need to make SSH connections from a Visual
Basic application. In addition, all the preliminary work to turn it
into a DLL would be necessary first; and furthermore, we don't even
know how to write VB components.

If someone offers to do some of this work for us, we might consider
it, but unless that happens I can't see VB integration being
anywhere other than the very bottom of our priority list.

\S{faq-ipc}{Question} How can I use PuTTY to make an SSH connection
from within another program?

Probably your best bet is to use Plink, the command-line connection
tool. If you can start Plink as a second Windows process, and
arrange for your primary process to be able to send data to the
Plink process, and receive data from it, through pipes, then you
should be able to make SSH connections from your program.

This is what CVS for Windows does, for example.

\H{faq-details} Details of PuTTY's operation

\S{faq-term}{Question} What terminal type does PuTTY use?

For most purposes, PuTTY can be considered to be an \cw{xterm}
terminal.

PuTTY also supports some terminal control sequences not supported by
the real \cw{xterm}: notably the Linux console sequences that
reconfigure the colour palette, and the title bar control sequences
used by \cw{DECterm} (which are different from the \cw{xterm} ones;
PuTTY supports both).

By default, PuTTY announces its terminal type to the server as
\c{xterm}. If you have a problem with this, you can reconfigure it
to say something else; \c{vt220} might help if you have trouble.

\S{faq-settings}{Question} Where does PuTTY store its data?

PuTTY stores most of its data (saved sessions, SSH host keys) in the
Registry. The precise location is

\c HKEY_CURRENT_USER\Software\SimonTatham\PuTTY

and within that area, saved sessions are stored under \c{Sessions}
while host keys are stored under \c{SshHostKeys}.

PuTTY also requires a random number seed file, to improve the
unpredictability of randomly chosen data needed as part of the SSH
cryptography. This is stored by default in your Windows home
directory (\c{%HOMEDRIVE%\\%HOMEPATH%}), or in the actual Windows
directory (such as \c{C:\\WINDOWS}) if the home directory doesn't
exist, for example if you're using Win95. If you want to change the
location of the random number seed file, you can put your chosen
pathname in the Registry, at

\c HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\RandSeedFile

\H{faq-howto} HOWTO questions

\S{faq-startmax}{Question} How can I make PuTTY start up maximised?

Create a Windows shortcut to start PuTTY from, and set it as \q{Run
Maximized}.

\S{faq-startsess}{Question} How can I create a Windows shortcut to
start a particular saved session directly?

To run a PuTTY session saved under the name \q{\cw{mysession}},
create a Windows shortcut that invokes PuTTY with a command line
like

\c \path\name\to\putty.exe -load mysession

(Note: prior to 0.53, the syntax was \c{@session}. This is now
deprecated and may be removed at some point.)

\S{faq-startssh}{Question} How can I start an SSH session straight
from the command line?

Use the command line \c{putty -ssh host.name}. Alternatively, create
a saved session that specifies the SSH protocol, and start the saved
session as shown in \k{faq-startsess}.

\S{faq-cutpaste}{Question} How do I copy and paste between PuTTY and
other Windows applications?

Copy and paste works similarly to the X Window System. You use the
left mouse button to select text in the PuTTY window. The act of
selection \e{automatically} copies the text to the clipboard: there
is no need to press Ctrl-Ins or Ctrl-C or anything else. In fact,
pressing Ctrl-C will send a Ctrl-C character to the other end of
your connection (just like it does the rest of the time), which may
have unpleasant effects. The \e{only} thing you need to do, to copy
text to the clipboard, is to select it.

To paste the clipboard contents into a PuTTY window, by default you
click the right mouse button. If you have a three-button mouse and
are used to X applications, you can configure pasting to be done by
the middle button instead, but this is not the default because most
Windows users don't have a middle button at all.

You can also paste by pressing Shift-Ins.

\S{faq-tunnels}{Question} How do I use X forwarding and port
forwarding? I can't find the Tunnels panel.

This is a new feature in version 0.52. You should upgrade.

\S{faq-options}{Question} How do I use all PuTTY's features (public
keys, proxying, cipher selection, etc.) in PSCP, PSFTP and Plink?

Most major features (e.g., public keys, port forwarding) are available
through command line options. See the documentation.

Not all features are accessible from the command line yet, although
we'd like to fix this. In the meantime, 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}{Question} How do I use PSCP.EXE? When I double-click it
gives me a command prompt window which then closes instantly.

PSCP is a command-line application, not a GUI application. If you
run it without arguments, it will simply print a help message and
terminate.

To use PSCP properly, run it from a Command Prompt window. See
\k{pscp} in the documentation for more details.

\S{faq-pscp-spaces}{Question} How do I use PSCP to copy a file whose
name has spaces in?

If PSCP is using the traditional SCP protocol, this is confusing. If
you're specifying a file at the local end, you just use one set of
quotes as you would normally do:

\c pscp "local filename with spaces" user@host:
\c pscp user@host:myfile "local filename with spaces"

But if the filename you're specifying is on the \e{remote} side, you
have to use backslashes and two sets of quotes:

\c pscp user@host:"\"remote filename with spaces\"" local_filename
\c pscp local_filename user@host:"\"remote filename with spaces\""

Worse still, in a remote-to-local copy you have to specify the local
file name explicitly, otherwise PSCP will complain that they don't
match (unless you specified the \c{-unsafe} option). The following
command will give an error message:

\c c:\>pscp user@host:"\"oo er\"" .
\c warning: remote host tried to write to a file called 'oo er'
\c          when we requested a file called '"oo er"'.

Instead, you need to specify the local file name in full:

\c c:\>pscp user@host:"\"oo er\"" "oo er"

If PSCP is using the newer SFTP protocol, none of this is a problem,
and all filenames with spaces in are specified using a single pair
of quotes in the obvious way:

\c pscp "local file" user@host:
\c pscp user@host:"remote file" .

\H{faq-trouble} Troubleshooting

\S{faq-incorrect-mac}{Question} Why do I see \q{Incorrect MAC
received on packet}?

This is due to a bug in old SSH 2 servers distributed by
\cw{ssh.com}. Version 2.3.0 and below of their SSH 2 server
constructs Message Authentication Codes in the wrong way, and
expects the client to construct them in the same wrong way. PuTTY
constructs the MACs correctly by default, and hence these old
servers will fail to work with it.

If you are using PuTTY version 0.52 or better, this should work
automatically: PuTTY should detect the buggy servers from their
version number announcement, and automatically start to construct
its MACs in the same incorrect manner as they do, so it will be able
to work with them.

If you are using PuTTY version 0.51 or below, you can enable the
workaround by going to the SSH panel and ticking the box labelled
\q{Imitate SSH 2 MAC bug}. It's possible that you might have to do
this with 0.52 as well, if a buggy server exists that PuTTY doesn't
know about.

In this context MAC stands for Message Authentication Code. It's a
cryptographic term, and it has nothing at all to do with Ethernet
MAC (Media Access Control) addresses.

\S{faq-pscp-protocol}{Question} Why do I see \q{Fatal: Protocol
error: Expected control record} in PSCP?

This happens because PSCP was expecting to see data from the server
that was part of the PSCP protocol exchange, and instead it saw data
that it couldn't make any sense of at all.

This almost always happens because the startup scripts in your
account on the server machine are generating output. This is
impossible for PSCP, or any other SCP client, to work around. You
should never use startup files (\c{.bashrc}, \c{.cshrc} and so on)
which generate output in non-interactive sessions.

This is not actually a PuTTY problem. If PSCP fails in this way,
then all other SCP clients are likely to fail in exactly the same
way. The problem is at the server end.

\S{faq-colours}{Question} I clicked on a colour in the Colours
panel, and the colour didn't change in my terminal.

That isn't how you're supposed to use the Colours panel.

During the course of a session, PuTTY potentially uses \e{all} the
colours listed in the Colours panel. It's not a question of using
only one of them and you choosing which one; PuTTY will use them
\e{all}. The purpose of the Colours panel is to let you adjust the
appearance of all the colours. So to change the colour of the
cursor, for example, you would select \q{Cursor Colour}, press the
\q{Modify} button, and select a new colour from the dialog box that
appeared. Similarly, if you want your session to appear in green,
you should select \q{Default Foreground} and press \q{Modify}.
Clicking on \q{ANSI Green} won't turn your session green; it will
only allow you to adjust the \e{shade} of green used when PuTTY is
instructed by the server to display green text.

\S{faq-winsock2}{Question} Plink on Windows 95 says it can't find
\cw{WS2_32.DLL}.

Plink requires the extended Windows network library, WinSock version
2. This is installed as standard on Windows 98 and above, and on
Windows NT, and even on later versions of Windows 95; but early
Win95 installations don't have it.

In order to use Plink on these systems, you will need to download
the
\W{http://www.microsoft.com/windows95/downloads/contents/wuadmintools/s_wunetworkingtools/w95sockets2/}{WinSock 2 upgrade}:

\c http://www.microsoft.com/windows95/downloads/contents/wuadmintools/
\c   s_wunetworkingtools/w95sockets2/

\S{faq-rekey}{Question} My PuTTY sessions close after an hour and
tell me \q{Server failed host key check}.

This is a bug in all versions of PuTTY up to and including 0.51. SSH
v2 servers from \cw{ssh.com} will require the key exchange to be
repeated one hour after the start of the connection, and PuTTY will
get this wrong.

Upgrade to version 0.52 or better and the problem should go away.

\S{faq-outofmem}{Question} After trying to establish an SSH 2
connection, PuTTY says \q{Out of memory} and dies.

If this happens just while the connection is starting up, this often
indicates that for some reason the client and server have failed to
establish a session encryption key. Somehow, they have performed
calculations that should have given each of them the same key, but
have ended up with different keys; so data encrypted by one and
decrypted by the other looks like random garbage.

This causes an \q{out of memory} error because the first encrypted
data PuTTY expects to see is the length of an SSH message. Normally
this will be something well under 100 bytes. If the decryption has
failed, PuTTY will see a completely random length in the region of
two \e{gigabytes}, and will try to allocate enough memory to store
this non-existent message. This will immediately lead to it thinking
it doesn't have enough memory, and panicking.

If this happens to you, it is quite likely to still be a PuTTY bug
and you should report it (although it might be a bug in your SSH
server instead); but it doesn't necessarily mean you've actually run
out of memory.

\S{faq-outofmem2}{Question} When attempting a file transfer, either
PSCP or PSFTP says \q{Out of memory} and dies.

This is almost always caused by your login scripts on the server
generating output. PSCP or PSFTP will receive that output when they
were expecting to see the start of a file transfer protocol, and
they will attempt to interpret the output as file-transfer protocol.
This will usually lead to an \q{out of memory} error for much the
same reasons as given in \k{faq-outofmem}.

This is a setup problem in your account on your server, \e{not} a
PSCP/PSFTP bug. Your login scripts should \e{never} generate output
during non-interactive sessions; secure file transfer is not the
only form of remote access that will break if they do.

On Unix, a simple fix is to ensure that all the parts of your login
script that might generate output are in \c{.profile} (if you use a
Bourne shell derivative) or \c{.login} (if you use a C shell).
Putting them in more general files such as \c{.bashrc} or \c{.cshrc}
is liable to lead to problems.

\S{faq-psftp-slow}{Question} PSFTP transfers files much slower than PSCP.

We believe this is because the SFTP and SSH2 protocols are less
efficient at bulk data transfer than SCP and SSH1, because every
block of data transferred requires an acknowledgment from the far
end. It would in theory be possible to queue several blocks of data
to get round this speed problem, but as yet we haven't done the
coding. If you really want this fixed, feel free to offer to help.

\S{faq-bce}{Question} 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}{Question} 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}{Question} I can't type characters that require the
AltGr key.

In PuTTY version 0.51, the AltGr key was broken. Upgrade to version
0.52 or better.

\S{faq-idleout}{Question} My PuTTY sessions unexpectedly close after
they are idle for a while.

Some types of firewall, and almost any router doing Network Address
Translation (NAT, also known as IP masquerading), will forget about
a connection through them if the connection does nothing for too
long. This will cause the connection to be rudely cut off when
contact is resumed.

You can try to combat this by telling PuTTY to send \e{keepalives}:
packets of data which have no effect on the actual session, but
which reassure the router or firewall that the network connection is
still active and worth remembering about.

Keepalives don't solve everything, unfortunately; although they
cause greater robustness against this sort of router, they can also
cause a \e{loss} of robustness against network dropouts. See
\k{config-keepalive} in the documentation for more discussion of
this.

\S{faq-timeout}{Question} PuTTY's network connections time out too
quickly when network connectivity is temporarily lost.

This is a Windows problem, not a PuTTY problem. The timeout value
can't be set on per application or per session basis. To increase
the TCP timeout globally, you need to tinker with the Registry.

On Windows 95, 98 or ME, the registry key you need to change is

\c HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\
\c   MSTCP\MaxDataRetries

(it must be of type DWORD in Win95, or String in Win98/ME).

On Windows NT or 2000, the registry key is

\c HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
\c   Parameters\TcpMaxDataRetransmissions

and it must be of type DWORD.

Set the key's value to something like 10. This will cause Windows to
try harder to keep connections alive instead of abandoning them.

\S{faq-puttyputty}{Question} When I \cw{cat} a binary file, I get
`PuTTYPuTTYPuTTY' on my command line.

Don't do that, then.

This is designed behaviour; when PuTTY receives the character
Control-E from the remote server, it interprets it as a request to
identify itself, and so it sends back the string \q{\cw{PuTTY}} as
if that string had been entered at the keyboard. Control-E should
only be sent by programs that are prepared to deal with the
response. Writing a binary file to your terminal is likely to output
many Control-E characters, and cause this behaviour. Don't do it.
It's a bad plan.

To mitigate the effects, you could configure the answerback string
to be empty (see \k{config-answerback}); but writing binary files to
your terminal is likely to cause various other unpleasant behaviour,
so this is only a small remedy.

\S{faq-wintitle}{Question} When I \cw{cat} a binary file, my window
title changes to a nonsense string.

Don't do that, then.

It is designed behaviour that PuTTY should have the ability to
adjust the window title on instructions from the server. Normally
the control sequence that does this should only be sent
deliberately, by programs that know what they are doing and intend
to put meaningful text in the window title. Writing a binary file to
your terminal runs the risk of sending the same control sequence by
accident, and cause unexpected changes in the window title. Don't do
it.

\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 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 "Assertion failed! Expression:
(len & 15) == 0" in sshaes.c, or "Out of memory", or crashes)

\b SSH 2 with 3DES (PuTTY says "Incorrect MAC received on packet")

\b SSH 1 with Blowfish (PuTTY says "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 "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. SSH1 and SSH2 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 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 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.

\H{faq-secure} Security questions

\S{faq-publicpc}{Question} Is it safe for me to download PuTTY and
use it on a public PC?

It depends on whether you trust that PC. If you don't trust the
public PC, don't use PuTTY on it, and don't use any other software
you plan to type passwords into either. It might be watching your
keystrokes, or it might tamper with the PuTTY binary you download.
There is \e{no} program safe enough that you can run it on an
actively malicious PC and get away with typing passwords into it.

If you do trust the PC, then it's probably OK to use PuTTY on it
(but if you don't trust the network, then the PuTTY download might
be tampered with, so it would be better to carry PuTTY with you on a
floppy).

\S{faq-cleanup}{Question} What does PuTTY leave on a system? How can
I clean up after it?

PuTTY will leave some Registry entries, and a random seed file, on
the PC (see \k{faq-settings}). If you are using PuTTY on a public
PC, or somebody else's PC, you might want to clean these up when you
leave. You can do that automatically, by running the command
\c{putty -cleanup}.

\S{faq-dsa}{Question} How come PuTTY now supports DSA, when the
website used to say how insecure it was?

DSA has a major weakness \e{if badly implemented}: it relies on a
random number generator to far too great an extent. If the random
number generator produces a number an attacker can predict, the DSA
private key is exposed - meaning that the attacker can log in as you
on all systems that accept that key.

The PuTTY policy changed because the developers were informed of
ways to implement DSA which do not suffer nearly as badly from this
weakness, and indeed which don't need to rely on random numbers at
all. For this reason we now believe PuTTY's DSA implementation is
probably OK. However, if you have the choice, we still recommend you
use RSA instead.

\S{faq-virtuallock}{Question} Couldn't Pageant use
\cw{VirtualLock()} to stop private keys being written to disk?

Unfortunately not. The \cw{VirtualLock()} function in the Windows
API doesn't do a proper job: it may prevent small pieces of a
process's memory from being paged to disk while the process is
running, but it doesn't stop the process's memory as a whole from
being swapped completely out to disk when the process is long-term
inactive. And Pageant spends most of its time inactive.

\H{faq-admin} Administrative questions

\S{faq-domain}{Question} Would you like me to register you a nicer
domain name?

No, thank you. Even if you can find one (most of them seem to have
been registered already, by people who didn't ask whether we
actually wanted it before they applied), we're happy with the PuTTY
web site being exactly where it is. It's not hard to find (just type
\q{putty} into \W{http://www.google.com/}{google.com} and we're the
first link returned), and we don't believe the administrative hassle
of moving the site would be worth the benefit.

In addition, if we \e{did} want a custom domain name, we would want
to run it ourselves, so we knew for certain that it would continue
to point where we wanted it, and wouldn't suddenly change or do
strange things. Having it registered for us by a third party who we
don't even know is not the best way to achieve this.

\S{faq-webhosting}{Question} Would you like free web hosting for the
PuTTY web site?

We already have some, thanks.

\S{faq-sourceforge}{Question} Why don't you move PuTTY to
SourceForge?

Partly, because we don't want to move the web site location (see
\k{faq-domain}).

Also, security reasons. PuTTY is a security product, and as such it
is particularly important to guard the code and the web site against
unauthorised modifications which might introduce subtle security
flaws. Therefore, we prefer that the CVS repository, web site and
FTP site remain where they are, under the direct control of system
administrators we know and trust personally, rather than being run
by a large organisation full of people we've never met and which is
known to have had breakins in the past.

No offence to SourceForge; I think they do a wonderful job. But
they're not ideal for everyone, and in particular they're not ideal
for us.

\S{faq-mailinglist1}{Question} Why can't I subscribe to the
putty-bugs mailing list?

Because you're not a member of the PuTTY core development team. The
putty-bugs mailing list is not a general newsgroup-like discussion
forum; it's a contact address for the core developers, and an
\e{internal} mailing list for us to discuss things among ourselves.
If we opened it up for everybody to subscribe to, it would turn into
something more like a newsgroup and we would be completely
overwhelmed by the volume of traffic. It's hard enough to keep up
with the list as it is.

\S{faq-mailinglist2}{Question} If putty-bugs isn't a
general-subscription mailing list, what is?

There isn't one, that we know of.

If someone else wants to set up a mailing list or other forum for
PuTTY users to help each other with common problems, that would be
fine with us, though the PuTTY team would almost certainly not have the
time to read it.  It's probably better to use the established
newsgroup \cw{comp.security.ssh} for this purpose.

\S{faq-donations}{Question} How can I donate to PuTTY development?

Please, \e{please} don't feel you have to. PuTTY is completely free
software, and not shareware. We think it's very important that
\e{everybody} who wants to use PuTTY should be able to, whether they
have any money or not; so the last thing we would want is for a
PuTTY user to feel guilty because they haven't paid us any money. If
you want to keep your money, please do keep it. We wouldn't dream of
asking for any.

Having said all that, if you still really \e{want} to give us money,
we won't argue :-) The easiest way for us to accept donations is if
you go to \W{http://www.e-gold.com}\cw{www.e-gold.com}, and deposit
your donation in account number 174769. Then send us e-mail to let
us know you've done so (otherwise we might not notice for months!).
Alternatively, if e-gold isn't convenient for you, you can donate to
\cw{<anakin@pobox.com>} using PayPal
(\W{http://www.paypal.com/}\cw{www.paypal.com}).

Small donations (tens of dollars or tens of euros) will probably be
spent on beer or curry, which helps motivate our volunteer team to
continue doing this for the world. Larger donations will be spent on
something that actually helps development, if we can find anything
(perhaps new hardware, or a copy of Windows XP), but if we can't
find anything then we'll just distribute the money among the
developers. If you want to be sure your donation is going towards
something worthwhile, ask us first. If you don't like these terms,
feel perfectly free not to donate. We don't mind.

\H{faq-misc} Miscellaneous questions

\S{faq-openssh}{Question} Is PuTTY a port of OpenSSH, or based on
OpenSSH?

No, it isn't. PuTTY is almost completely composed of code written
from scratch for PuTTY. The only code we share with OpenSSH is the
detector for SSH1 CRC compensation attacks, written by CORE SDI S.A.

\S{faq-sillyputty}{Question} Where can I buy silly putty?

You're looking at the wrong web site; the only PuTTY we know about
here is the name of a computer program.

If you want the kind of putty you can buy as an executive toy, the
PuTTY team can personally recommend Thinking Putty, which you can
buy from Crazy Aaron's Putty World, at
\W{http://www.puttyworld.com}\cw{www.puttyworld.com}.

\S{faq-meaning}{Question} What does \q{PuTTY} mean?

It's the name of a popular SSH and Telnet client.  Any other meaning
is in the eye of the beholder.  It's been rumoured that \q{PuTTY}
is the antonym of \q{\cw{getty}}, or that it's the stuff that makes your
Windows useful, or that it's a kind of plutonium Teletype.  We
couldn't possibly comment on such allegations.

\S{faq-pronounce}{Question} How do I pronounce \q{PuTTY}?

Exactly like the English word \q{putty}, which we pronounce
/\u02C8{'}p\u028C{V}t\u026A{I}/.