зеркало из https://github.com/github/putty.git
942 строки
40 KiB
Plaintext
942 строки
40 KiB
Plaintext
\versionid $Id: faq.but,v 1.39 2002/11/22 00:07:31 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.html}{Wishlist
|
|
page}, and see if you can find the feature there. If it's on there,
|
|
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} 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}).
|
|
|
|
\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 for PuTTY users to
|
|
help each other with common problems, that would be fine with us;
|
|
but the PuTTY team would almost certainly not have the time to read
|
|
it, so any questions the list couldn't answer would have to be
|
|
forwarded on to us by the questioner. In any case, 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-pronounce}{Question} How do I pronounce PuTTY?
|
|
|
|
Exactly like the normal word \q{putty}. Just like the stuff you put
|
|
on window frames. (One of the reasons it's called PuTTY is because
|
|
it makes Windows usable. :-)
|