faq.but

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.)

\S{faq-xpwontrun}{Question} PuTTY fails to start up.  Windows claims that
\q{the application configuration is incorrect}.

This is caused by a bug in certain versions of \i{Windows XP} which
is triggered by PuTTY 0.58. This was fixed in 0.59. The
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/xp-wont-run}{\q{xp-wont-run}}
entry in PuTTY's wishlist has more details.

\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 \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}. (Note that this only removes settings for
the currently logged-in user on \i{multi-user systems}.)

If PuTTY was installed from the installer package, it will also
appear in \q{Add/Remove Programs}. Older versions of the uninstaller
do not remove the above-mentioned registry entries and file.

\S{faq-dsa}{Question} How come PuTTY now supports \i{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-link}{Question} Would you link to my web site from the PuTTY
web site?

Only if the content of your web page is of definite direct interest
to PuTTY users. If your content is unrelated, or only tangentially
related, to PuTTY, then the link would simply be advertising for
you.

One very nice effect of the Google ranking mechanism is that by and
large, the most popular web sites get the highest rankings. This
means that when an ordinary person does a search, the top item in
the search is very likely to be a high-quality site or the site they
actually wanted, rather than the site which paid the most money for
its ranking.

The PuTTY web site is held in high esteem by Google, for precisely
this reason: lots of people have linked to it simply because they
like PuTTY, without us ever having to ask anyone to link to us. We
feel that it would be an abuse of this esteem to use it to boost the
ranking of random advertisers' web sites. If you want your web site
to have a high Google ranking, we'd prefer that you achieve this the
way we did - by being good enough at what you do that people will
link to you simply because they like you.

In particular, we aren't interested in trading links for money (see
above), and we \e{certainly} aren't interested in trading links for
other links (since we have no advertising on our web site, our
Google ranking is not even directly worth anything to us). If we
don't want to link to you for free, then we probably won't want to
link to you at all.

If you have software based on PuTTY, or specifically designed to
interoperate with PuTTY, or in some other way of genuine interest to
PuTTY users, then we will probably be happy to add a link to you on
our Links page. And if you're running a mirror of the PuTTY web
site, we're \e{definitely} interested.

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