faq.but

putty

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 SSH2 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 \ii{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 \i{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 \ii{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 \i{Windows 95} says it can't find
\i\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/
\c   wuadmintools/s_wunetworkingtools/w95sockets2/

\S{faq-outofmem}{Question} After trying to establish an SSH-2
connection, PuTTY says \q{\ii{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{\ii{Out of memory}} and dies.

This is almost always caused by your \i{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.

The throughput of PSFTP 0.54 should be much better than 0.53b and
prior; we've added code to the SFTP backend to queue several blocks
of data rather than waiting for an acknowledgement for each. (The
SCP backend did not suffer from this performance issue because SCP
is a much simpler protocol.)

\S{faq-bce}{Question} When I run full-colour applications, I see
areas of black space where colour ought to be, or vice versa.

You almost certainly need to change the \q{Use \i{background colour} to
erase screen} setting in the Terminal panel. If there is too much
black space (the commoner situation), you should enable it, while if
there is too much colour, you should disable it. (See \k{config-erase}.)

In old versions of PuTTY, this was disabled by default, and would not
take effect until you reset the terminal (see \k{faq-resetterm}).
Since 0.54, it is enabled by default, and changes take effect
immediately.

\S{faq-resetterm}{Question} When I change some terminal settings,
nothing happens.

Some of the terminal options (notably \ii{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.

In versions 0.53b and prior, if you 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.

In version 0.54, the behaviour has changed - changes to these
settings take effect immediately.

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

Some types of \i{firewall}, and almost any router doing Network Address
Translation (\i{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 \I{breaks in connectivity}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 create or
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).
(See MS Knowledge Base article
\W{http://support.microsoft.com/default.aspx?scid=kb;en-us;158474}{158474}
for more information.)

On Windows NT, 2000, or XP, the registry key to create or change is

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

and it must be of type DWORD.
(See MS Knowledge Base articles
\W{http://support.microsoft.com/default.aspx?scid=kb;en-us;120642}{120642}
and
\W{http://support.microsoft.com/default.aspx?scid=kb;en-us;314053}{314053}
for more information.)

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
\q{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 \i{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 \i{keyboard} stops working once
PuTTY displays the \i{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 \I{keyboard}\i{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 \i{Unix} system is to
type the command \i\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.