1 \define{versionidfaq} \versionid $Id: faq.but 8733 2009-11-01 22:06:05Z jacob $
\r
3 \A{faq} PuTTY \i{FAQ}
\r
5 This FAQ is published on the PuTTY web site, and also provided as an
\r
6 appendix in the manual.
\r
8 \H{faq-intro} Introduction
\r
10 \S{faq-what}{Question} What is PuTTY?
\r
12 PuTTY is a client program for the SSH, Telnet and Rlogin network
\r
15 These protocols are all used to run a remote session on a computer,
\r
16 over a network. PuTTY implements the client end of that session: the
\r
17 end at which the session is displayed, rather than the end at which
\r
20 In really simple terms: you run PuTTY on a Windows machine, and tell
\r
21 it to connect to (for example) a Unix machine. PuTTY opens a window.
\r
22 Then, anything you type into that window is sent straight to the
\r
23 Unix machine, and everything the Unix machine sends back is
\r
24 displayed in the window. So you can work on the Unix machine as if
\r
25 you were sitting at its console, while actually sitting somewhere
\r
28 \H{faq-support} Features supported in PuTTY
\r
30 \I{supported features}In general, if you want to know if PuTTY supports
\r
31 a particular feature, you should look for it on the
\r
32 \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/}{PuTTY web site}.
\r
36 \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html}{changes
\r
37 page}, and see if you can find the feature on there. If a feature is
\r
38 listed there, it's been implemented. If it's listed as a change made
\r
39 \e{since} the latest version, it should be available in the
\r
40 development snapshots, in which case testing will be very welcome.
\r
43 \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/}{Wishlist
\r
44 page}, and see if you can find the feature there. If it's on there,
\r
45 and not in the \q{Recently fixed} section, it probably \e{hasn't} been
\r
48 \S{faq-ssh2}{Question} Does PuTTY support SSH-2?
\r
50 Yes. SSH-2 support has been available in PuTTY since version 0.50.
\r
52 Public key authentication (both RSA and DSA) in SSH-2 is new in
\r
55 \S{faq-ssh2-keyfmt}{Question} Does PuTTY support reading OpenSSH or
\r
56 \cw{ssh.com} SSH-2 private key files?
\r
58 PuTTY doesn't support this natively (see
\r
59 \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/key-formats-natively.html}{the wishlist entry}
\r
60 for reasons why not), but as of 0.53
\r
61 PuTTYgen can convert both OpenSSH and \cw{ssh.com} private key
\r
62 files into PuTTY's format.
\r
64 \S{faq-ssh1}{Question} Does PuTTY support SSH-1?
\r
66 Yes. SSH-1 support has always been available in PuTTY.
\r
68 \S{faq-localecho}{Question} Does PuTTY support \i{local echo}?
\r
70 Yes. Version 0.52 has proper support for local echo.
\r
72 In version 0.51 and before, local echo could not be separated from
\r
73 local line editing (where you type a line of text locally, and it is
\r
74 not sent to the server until you press Return, so you have the
\r
75 chance to edit it and correct mistakes \e{before} the server sees
\r
76 it). New in version 0.52, local echo and local line editing are
\r
77 separate options, and by default PuTTY will try to determine
\r
78 automatically whether to enable them or not, based on which protocol
\r
79 you have selected and also based on hints from the server. If you
\r
80 have a problem with PuTTY's default choice, you can force each
\r
81 option to be enabled or disabled as you choose. The controls are in
\r
82 the Terminal panel, in the section marked \q{Line discipline
\r
85 \S{faq-savedsettings}{Question} Does PuTTY support storing settings,
\r
86 so I don't have to change them every time?
\r
88 Yes, all of PuTTY's settings can be saved in named session profiles.
\r
89 You can also change the default settings that are used for new sessions.
\r
90 See \k{config-saving} in the documentation for how to do this.
\r
92 \S{faq-disksettings}{Question} Does PuTTY support storing its
\r
93 settings in a disk file?
\r
95 Not at present, although \k{config-file} in the documentation gives
\r
96 a method of achieving the same effect.
\r
98 \S{faq-fullscreen}{Question} Does PuTTY support full-screen mode,
\r
101 Yes; this is a new feature in version 0.52.
\r
103 \S{faq-password-remember}{Question} Does PuTTY have the ability to
\r
104 \i{remember my password} so I don't have to type it every time?
\r
108 Remembering your password is a bad plan for obvious security
\r
109 reasons: anyone who gains access to your machine while you're away
\r
110 from your desk can find out the remembered password, and use it,
\r
111 abuse it or change it.
\r
113 In addition, it's not even \e{possible} for PuTTY to automatically
\r
114 send your password in a Telnet session, because Telnet doesn't give
\r
115 the client software any indication of which part of the login
\r
116 process is the password prompt. PuTTY would have to guess, by
\r
117 looking for words like \q{password} in the session data; and if your
\r
118 login program is written in something other than English, this won't
\r
121 In SSH, remembering your password would be possible in theory, but
\r
122 there doesn't seem to be much point since SSH supports public key
\r
123 authentication, which is more flexible and more secure. See
\r
124 \k{pubkey} in the documentation for a full discussion of public key
\r
127 \S{faq-hostkeys}{Question} Is there an option to turn off the
\r
128 \I{verifying the host key}annoying host key prompts?
\r
130 No, there isn't. And there won't be. Even if you write it yourself
\r
131 and send us the patch, we won't accept it.
\r
133 Those annoying host key prompts are the \e{whole point} of SSH.
\r
134 Without them, all the cryptographic technology SSH uses to secure
\r
135 your session is doing nothing more than making an attacker's job
\r
136 slightly harder; instead of sitting between you and the server with
\r
137 a packet sniffer, the attacker must actually subvert a router and
\r
138 start modifying the packets going back and forth. But that's not all
\r
139 that much harder than just sniffing; and without host key checking,
\r
140 it will go completely undetected by client or server.
\r
142 Host key checking is your guarantee that the encryption you put on
\r
143 your data at the client end is the \e{same} encryption taken off the
\r
144 data at the server end; it's your guarantee that it hasn't been
\r
145 removed and replaced somewhere on the way. Host key checking makes
\r
146 the attacker's job \e{astronomically} hard, compared to packet
\r
147 sniffing, and even compared to subverting a router. Instead of
\r
148 applying a little intelligence and keeping an eye on Bugtraq, the
\r
149 attacker must now perform a brute-force attack against at least one
\r
150 military-strength cipher. That insignificant host key prompt really
\r
151 does make \e{that} much difference.
\r
153 If you're having a specific problem with host key checking - perhaps
\r
154 you want an automated batch job to make use of PSCP or Plink, and
\r
155 the interactive host key prompt is hanging the batch process - then
\r
156 the right way to fix it is to add the correct host key to the
\r
157 Registry in advance. That way, you retain the \e{important} feature
\r
158 of host key checking: the right key will be accepted and the wrong
\r
159 ones will not. Adding an option to turn host key checking off
\r
160 completely is the wrong solution and we will not do it.
\r
162 If you have host keys available in the common \i\c{known_hosts} format,
\r
163 we have a script called
\r
164 \W{http://svn.tartarus.org/sgt/putty/contrib/kh2reg.py?view=markup}\c{kh2reg.py}
\r
165 to convert them to a Windows .REG file, which can be installed ahead of
\r
166 time by double-clicking or using \c{REGEDIT}.
\r
168 \S{faq-server}{Question} Will you write an SSH server for the PuTTY
\r
169 suite, to go with the client?
\r
171 No. The only reason we might want to would be if we could easily
\r
172 re-use existing code and significantly cut down the effort. We don't
\r
173 believe this is the case; there just isn't enough common ground
\r
174 between an SSH client and server to make it worthwhile.
\r
176 If someone else wants to use bits of PuTTY in the process of writing
\r
177 a Windows SSH server, they'd be perfectly welcome to of course, but
\r
178 I really can't see it being a lot less effort for us to do that than
\r
179 it would be for us to write a server from the ground up. We don't
\r
180 have time, and we don't have motivation. The code is available if
\r
181 anyone else wants to try it.
\r
183 \S{faq-pscp-ascii}{Question} Can PSCP or PSFTP transfer files in
\r
188 Until recently, this was a limitation of the file transfer protocols:
\r
189 the SCP and SFTP protocols had no notion of transferring a file in
\r
190 anything other than binary mode. (This is still true of SCP.)
\r
192 The current draft protocol spec of SFTP proposes a means of
\r
193 implementing ASCII transfer. At some point PSCP/PSFTP may implement
\r
196 \H{faq-ports} Ports to other operating systems
\r
198 The eventual goal is for PuTTY to be a multi-platform program, able
\r
199 to run on at least Windows, Mac OS and Unix.
\r
201 Porting will become easier once PuTTY has a generalised porting
\r
202 layer, drawing a clear line between platform-dependent and
\r
203 platform-independent code. The general intention was for this
\r
204 porting layer to evolve naturally as part of the process of doing
\r
205 the first port; a Unix port has now been released and the plan
\r
206 seems to be working so far.
\r
208 \S{faq-ports-general}{Question} What ports of PuTTY exist?
\r
210 Currently, release versions of PuTTY tools only run on full Win32
\r
211 systems and Unix. \q{\i{Win32}} includes versions of Windows from
\r
212 Windows 95 onwards (as opposed to the 16-bit Windows 3.1; see
\r
213 \k{faq-win31}), up to and including Windows 7; and we know of no
\r
214 reason why PuTTY should not continue to work on future versions
\r
217 The Windows executables we provide are for the 32-bit \q{\i{x86}}
\r
218 processor architecture, but they should work fine on 64-bit
\r
219 processors that are backward-compatible with that architecture.
\r
220 (We used to also provide executables for Windows for the Alpha
\r
221 processor, but stopped after 0.58 due to lack of interest.)
\r
223 In the development code, partial ports to the Mac OSes exist (see
\r
226 Currently PuTTY does \e{not} run on Windows CE (see \k{faq-wince}).
\r
228 We do not have release-quality ports for any other systems at the
\r
229 present time. If anyone told you we had an EPOC port, or an iPaq port,
\r
230 or any other port of PuTTY, they were mistaken. We don't.
\r
232 There are some third-party ports to various platforms, mentioned
\r
234 \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/links.html}{Links page of our website}.
\r
236 \S{faq-unix}{Question} \I{Unix version}Is there a port to Unix?
\r
238 As of 0.54, there are Unix ports of most of the traditional PuTTY
\r
239 tools, and also one entirely new application.
\r
241 If you look at the source release, you should find a \c{unix}
\r
242 subdirectory. There are a couple of ways of building it,
\r
243 including the usual \c{configure}/\c{make}; see the file \c{README}
\r
244 in the source distribution. This should build you Unix
\r
245 ports of Plink, PuTTY itself, PuTTYgen, PSCP, PSFTP, and also
\r
246 \i\c{pterm} - an \cw{xterm}-type program which supports the same
\r
247 terminal emulation as PuTTY. We do not yet have a Unix port of
\r
250 If you don't have \i{Gtk}, you should still be able to build the
\r
251 command-line tools.
\r
253 Note that Unix PuTTY has mostly only been tested on Linux so far;
\r
254 portability problems such as BSD-style ptys or different header file
\r
255 requirements are expected.
\r
257 \S{faq-unix-why}{Question} What's the point of the Unix port? Unix
\r
260 All sorts of little things. \c{pterm} is directly useful to anyone
\r
261 who prefers PuTTY's terminal emulation to \c{xterm}'s, which at
\r
262 least some people do. Unix Plink has apparently found a niche among
\r
263 people who find the complexity of OpenSSL makes OpenSSH hard to
\r
264 install (and who don't mind Plink not having as many features). Some
\r
265 users want to generate a large number of SSH keys on Unix and then
\r
266 copy them all into PuTTY, and the Unix PuTTYgen should allow them to
\r
267 automate that conversion process.
\r
269 There were development advantages as well; porting PuTTY to Unix was
\r
270 a valuable path-finding effort for other future ports, and also
\r
271 allowed us to use the excellent Linux tool
\r
272 \W{http://valgrind.kde.org/}{Valgrind} to help with debugging, which
\r
273 has already improved PuTTY's stability on \e{all} platforms.
\r
275 However, if you're a Unix user and you can see no reason to switch
\r
276 from OpenSSH to PuTTY/Plink, then you're probably right. We don't
\r
277 expect our Unix port to be the right thing for everybody.
\r
279 \S{faq-wince}{Question} Will there be a port to Windows CE or PocketPC?
\r
281 We have done some work on such a port, but it only reached an early
\r
282 stage, and certainly not a useful one. It's no longer being actively
\r
285 However, there's a third-party port at
\r
286 \W{http://www.pocketputty.net/}\c{http://www.pocketputty.net/}.
\r
288 \S{faq-win31}{Question} Is there a port to \i{Windows 3.1}?
\r
290 PuTTY is a 32-bit application from the ground up, so it won't run on
\r
291 Windows 3.1 as a native 16-bit program; and it would be \e{very}
\r
292 hard to port it to do so, because of Windows 3.1's vile memory
\r
293 allocation mechanisms.
\r
295 However, it is possible in theory to compile the existing PuTTY
\r
296 source in such a way that it will run under \i{Win32s} (an extension to
\r
297 Windows 3.1 to let you run 32-bit programs). In order to do this
\r
298 you'll need the right kind of C compiler - modern versions of Visual
\r
299 C at least have stopped being backwards compatible to Win32s. Also,
\r
300 the last time we tried this it didn't work very well.
\r
302 If you're interested in running PuTTY under Windows 3.1, help and
\r
303 testing in this area would be very welcome!
\r
305 \S{faq-mac-port}{Question} Will there be a port to the \I{Mac OS}Mac?
\r
307 There are several answers to this question:
\r
309 \b The Unix/Gtk port is already fully working under Mac OS X as an X11
\r
312 \b A native (Cocoa) Mac OS X port has been started. It's just about
\r
313 usable, but is of nowhere near release quality yet, and is likely to
\r
314 behave in unexpected ways. Currently it's unlikely to be completed
\r
315 unless someone steps in to help.
\r
317 \b A separate port to the classic Mac OS (pre-OSX) is also in
\r
318 progress; it too is not ready yet.
\r
320 \S{faq-epoc}{Question} Will there be a port to EPOC?
\r
322 I hope so, but given that ports aren't really progressing very fast
\r
323 even on systems the developers \e{do} already know how to program
\r
324 for, it might be a long time before any of us get round to learning
\r
325 a new system and doing the port for that.
\r
327 However, some of the work has been done by other people; see the
\r
328 \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/links.html}{Links page of our website}
\r
329 for various third-party ports.
\r
331 \S{faq-iphone}{Question} Will there be a port to the iPhone?
\r
333 We have no plans to write such a port ourselves; none of us has an
\r
334 iPhone, and developing and publishing applications for it looks
\r
335 awkward and expensive. Such a port would probably depend upon the
\r
336 stalled Mac OS X port (see \k{faq-mac-port}).
\r
338 However, there is a third-party SSH client for the iPhone and
\r
339 iPod\_Touch called \W{http://www.instantcocoa.com/products/pTerm/}{pTerm},
\r
340 which is apparently based on PuTTY. (This is nothing to do with our
\r
341 similarly-named \c{pterm}, which is a standalone terminal emulator for
\r
342 Unix systems; see \k{faq-unix}.)
\r
344 \H{faq-embedding} Embedding PuTTY in other programs
\r
346 \S{faq-dll}{Question} Is the SSH or Telnet code available as a DLL?
\r
348 No, it isn't. It would take a reasonable amount of rewriting for
\r
349 this to be possible, and since the PuTTY project itself doesn't
\r
350 believe in DLLs (they make installation more error-prone) none of us
\r
351 has taken the time to do it.
\r
353 Most of the code cleanup work would be a good thing to happen in
\r
354 general, so if anyone feels like helping, we wouldn't say no.
\r
357 \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/dll-frontend.html}{the wishlist entry}.
\r
359 \S{faq-vb}{Question} Is the SSH or Telnet code available as a Visual
\r
362 No, it isn't. None of the PuTTY team uses Visual Basic, and none of
\r
363 us has any particular need to make SSH connections from a Visual
\r
364 Basic application. In addition, all the preliminary work to turn it
\r
365 into a DLL would be necessary first; and furthermore, we don't even
\r
366 know how to write VB components.
\r
368 If someone offers to do some of this work for us, we might consider
\r
369 it, but unless that happens I can't see VB integration being
\r
370 anywhere other than the very bottom of our priority list.
\r
372 \S{faq-ipc}{Question} How can I use PuTTY to make an SSH connection
\r
373 from within another program?
\r
375 Probably your best bet is to use Plink, the command-line connection
\r
376 tool. If you can start Plink as a second Windows process, and
\r
377 arrange for your primary process to be able to send data to the
\r
378 Plink process, and receive data from it, through pipes, then you
\r
379 should be able to make SSH connections from your program.
\r
381 This is what CVS for Windows does, for example.
\r
383 \H{faq-details} Details of PuTTY's operation
\r
385 \S{faq-term}{Question} What \i{terminal type} does PuTTY use?
\r
387 For most purposes, PuTTY can be considered to be an \cw{xterm}
\r
390 PuTTY also supports some terminal \i{control sequences} not supported by
\r
391 the real \cw{xterm}: notably the Linux console sequences that
\r
392 reconfigure the colour palette, and the title bar control sequences
\r
393 used by \i\cw{DECterm} (which are different from the \cw{xterm} ones;
\r
394 PuTTY supports both).
\r
396 By default, PuTTY announces its terminal type to the server as
\r
397 \c{xterm}. If you have a problem with this, you can reconfigure it
\r
398 to say something else; \c{vt220} might help if you have trouble.
\r
400 \S{faq-settings}{Question} Where does PuTTY store its data?
\r
402 On Windows, PuTTY stores most of its data (saved sessions, SSH host
\r
403 keys) in the \i{Registry}. The precise location is
\r
405 \c HKEY_CURRENT_USER\Software\SimonTatham\PuTTY
\r
407 and within that area, saved sessions are stored under \c{Sessions}
\r
408 while host keys are stored under \c{SshHostKeys}.
\r
410 PuTTY also requires a random number seed file, to improve the
\r
411 unpredictability of randomly chosen data needed as part of the SSH
\r
412 cryptography. This is stored by default in a file called \i\c{PUTTY.RND};
\r
413 this is stored by default in the \q{Application Data} directory,
\r
414 or failing that, one of a number of fallback locations. If you
\r
415 want to change the location of the random number seed file, you can
\r
416 put your chosen pathname in the Registry, at
\r
418 \c HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\RandSeedFile
\r
420 You can ask PuTTY to delete all this data; see \k{faq-cleanup}.
\r
422 On Unix, PuTTY stores all of this data in a directory \cw{~/.putty}.
\r
424 \H{faq-howto} HOWTO questions
\r
426 \S{faq-login}{Question} What login name / password should I use?
\r
428 This is not a question you should be asking \e{us}.
\r
430 PuTTY is a communications tool, for making connections to other
\r
431 computers. We maintain the tool; we \e{don't} administer any computers
\r
432 that you're likely to be able to use, in the same way that the people
\r
433 who make web browsers aren't responsible for most of the content you can
\r
434 view in them. \#{FIXME: less technical analogy?} We cannot help with
\r
435 questions of this sort.
\r
437 If you know the name of the computer you want to connect to, but don't
\r
438 know what login name or password to use, you should talk to whoever
\r
439 administers that computer. If you don't know who that is, see the next
\r
440 question for some possible ways to find out.
\r
442 \# FIXME: some people ask us to provide them with a login name
\r
443 apparently as random members of the public rather than in the
\r
444 belief that we run a server belonging to an organisation they already
\r
445 have some relationship with. Not sure what to say to such people.
\r
447 \S{faq-commands}{Question} \I{commands on the server}What commands
\r
448 can I type into my PuTTY terminal window?
\r
450 Again, this is not a question you should be asking \e{us}. You need
\r
451 to read the manuals, or ask the administrator, of \e{the computer
\r
452 you have connected to}.
\r
454 PuTTY does not process the commands you type into it. It's only a
\r
455 communications tool. It makes a connection to another computer; it
\r
456 passes the commands you type to that other computer; and it passes
\r
457 the other computer's responses back to you. Therefore, the precise
\r
458 range of commands you can use will not depend on PuTTY, but on what
\r
459 kind of computer you have connected to and what software is running
\r
460 on it. The PuTTY team cannot help you with that.
\r
462 (Think of PuTTY as being a bit like a telephone. If you phone
\r
463 somebody up and you don't know what language to speak to make them
\r
464 understand you, it isn't \e{the telephone company}'s job to find
\r
465 that out for you. We just provide the means for you to get in touch;
\r
466 making yourself understood is somebody else's problem.)
\r
468 If you are unsure of where to start looking for the administrator of
\r
469 your server, a good place to start might be to remember how you
\r
470 found out the host name in the PuTTY configuration. If you were
\r
471 given that host name by e-mail, for example, you could try asking
\r
472 the person who sent you that e-mail. If your company's IT department
\r
473 provided you with ready-made PuTTY saved sessions, then that IT
\r
474 department can probably also tell you something about what commands
\r
475 you can type during those sessions. But the PuTTY maintainer team
\r
476 does not administer any server you are likely to be connecting to,
\r
477 and cannot help you with questions of this type.
\r
479 \S{faq-startmax}{Question} How can I make PuTTY start up \i{maximise}d?
\r
481 Create a Windows shortcut to start PuTTY from, and set it as \q{Run
\r
484 \S{faq-startsess}{Question} How can I create a \i{Windows shortcut} to
\r
485 start a particular saved session directly?
\r
487 To run a PuTTY session saved under the name \q{\cw{mysession}},
\r
488 create a Windows shortcut that invokes PuTTY with a command line
\r
491 \c \path\name\to\putty.exe -load "mysession"
\r
493 (Note: prior to 0.53, the syntax was \c{@session}. This is now
\r
494 deprecated and may be removed at some point.)
\r
496 \S{faq-startssh}{Question} How can I start an SSH session straight
\r
497 from the command line?
\r
499 Use the command line \c{putty -ssh host.name}. Alternatively, create
\r
500 a saved session that specifies the SSH protocol, and start the saved
\r
501 session as shown in \k{faq-startsess}.
\r
503 \S{faq-cutpaste}{Question} How do I \i{copy and paste} between PuTTY and
\r
504 other Windows applications?
\r
506 Copy and paste works similarly to the X Window System. You use the
\r
507 left mouse button to select text in the PuTTY window. The act of
\r
508 selection \e{automatically} copies the text to the clipboard: there
\r
509 is no need to press Ctrl-Ins or Ctrl-C or anything else. In fact,
\r
510 pressing Ctrl-C will send a Ctrl-C character to the other end of
\r
511 your connection (just like it does the rest of the time), which may
\r
512 have unpleasant effects. The \e{only} thing you need to do, to copy
\r
513 text to the clipboard, is to select it.
\r
515 To paste the clipboard contents into a PuTTY window, by default you
\r
516 click the right mouse button. If you have a three-button mouse and
\r
517 are used to X applications, you can configure pasting to be done by
\r
518 the middle button instead, but this is not the default because most
\r
519 Windows users don't have a middle button at all.
\r
521 You can also paste by pressing Shift-Ins.
\r
523 \S{faq-options}{Question} How do I use all PuTTY's features (public
\r
524 keys, proxying, cipher selection, etc.) in PSCP, PSFTP and Plink?
\r
526 Most major features (e.g., public keys, port forwarding) are available
\r
527 through command line options. See the documentation.
\r
529 Not all features are accessible from the command line yet, although
\r
530 we'd like to fix this. In the meantime, you can use most of
\r
531 PuTTY's features if you create a PuTTY saved session, and then use
\r
532 the name of the saved session on the command line in place of a
\r
533 hostname. This works for PSCP, PSFTP and Plink (but don't expect
\r
534 port forwarding in the file transfer applications!).
\r
536 \S{faq-pscp}{Question} How do I use PSCP.EXE? When I double-click it
\r
537 gives me a command prompt window which then closes instantly.
\r
539 PSCP is a command-line application, not a GUI application. If you
\r
540 run it without arguments, it will simply print a help message and
\r
543 To use PSCP properly, run it from a Command Prompt window. See
\r
544 \k{pscp} in the documentation for more details.
\r
546 \S{faq-pscp-spaces}{Question} \I{spaces in filenames}How do I use
\r
547 PSCP to copy a file whose name has spaces in?
\r
549 If PSCP is using the traditional SCP protocol, this is confusing. If
\r
550 you're specifying a file at the local end, you just use one set of
\r
551 quotes as you would normally do:
\r
553 \c pscp "local filename with spaces" user@host:
\r
554 \c pscp user@host:myfile "local filename with spaces"
\r
556 But if the filename you're specifying is on the \e{remote} side, you
\r
557 have to use backslashes and two sets of quotes:
\r
559 \c pscp user@host:"\"remote filename with spaces\"" local_filename
\r
560 \c pscp local_filename user@host:"\"remote filename with spaces\""
\r
562 Worse still, in a remote-to-local copy you have to specify the local
\r
563 file name explicitly, otherwise PSCP will complain that they don't
\r
564 match (unless you specified the \c{-unsafe} option). The following
\r
565 command will give an error message:
\r
567 \c c:\>pscp user@host:"\"oo er\"" .
\r
568 \c warning: remote host tried to write to a file called 'oo er'
\r
569 \c when we requested a file called '"oo er"'.
\r
571 Instead, you need to specify the local file name in full:
\r
573 \c c:\>pscp user@host:"\"oo er\"" "oo er"
\r
575 If PSCP is using the newer SFTP protocol, none of this is a problem,
\r
576 and all filenames with spaces in are specified using a single pair
\r
577 of quotes in the obvious way:
\r
579 \c pscp "local file" user@host:
\r
580 \c pscp user@host:"remote file" .
\r
582 \H{faq-trouble} Troubleshooting
\r
584 \S{faq-incorrect-mac}{Question} Why do I see \q{Incorrect MAC
\r
585 received on packet}?
\r
587 One possible cause of this that used to be common is a bug in old
\r
588 SSH-2 servers distributed by \cw{ssh.com}. (This is not the only
\r
589 possible cause; see \k{errors-crc} in the documentation.)
\r
590 Version 2.3.0 and below of their SSH-2 server
\r
591 constructs Message Authentication Codes in the wrong way, and
\r
592 expects the client to construct them in the same wrong way. PuTTY
\r
593 constructs the MACs correctly by default, and hence these old
\r
594 servers will fail to work with it.
\r
596 If you are using PuTTY version 0.52 or better, this should work
\r
597 automatically: PuTTY should detect the buggy servers from their
\r
598 version number announcement, and automatically start to construct
\r
599 its MACs in the same incorrect manner as they do, so it will be able
\r
602 If you are using PuTTY version 0.51 or below, you can enable the
\r
603 workaround by going to the SSH panel and ticking the box labelled
\r
604 \q{Imitate SSH2 MAC bug}. It's possible that you might have to do
\r
605 this with 0.52 as well, if a buggy server exists that PuTTY doesn't
\r
608 In this context MAC stands for \ii{Message Authentication Code}. It's a
\r
609 cryptographic term, and it has nothing at all to do with Ethernet
\r
610 MAC (Media Access Control) addresses.
\r
612 \S{faq-pscp-protocol}{Question} Why do I see \q{Fatal: Protocol
\r
613 error: Expected control record} in PSCP?
\r
615 This happens because PSCP was expecting to see data from the server
\r
616 that was part of the PSCP protocol exchange, and instead it saw data
\r
617 that it couldn't make any sense of at all.
\r
619 This almost always happens because the \i{startup scripts} in your
\r
620 account on the server machine are generating output. This is
\r
621 impossible for PSCP, or any other SCP client, to work around. You
\r
622 should never use startup files (\c{.bashrc}, \c{.cshrc} and so on)
\r
623 which generate output in non-interactive sessions.
\r
625 This is not actually a PuTTY problem. If PSCP fails in this way,
\r
626 then all other SCP clients are likely to fail in exactly the same
\r
627 way. The problem is at the server end.
\r
629 \S{faq-colours}{Question} I clicked on a colour in the \ii{Colours}
\r
630 panel, and the colour didn't change in my terminal.
\r
632 That isn't how you're supposed to use the Colours panel.
\r
634 During the course of a session, PuTTY potentially uses \e{all} the
\r
635 colours listed in the Colours panel. It's not a question of using
\r
636 only one of them and you choosing which one; PuTTY will use them
\r
637 \e{all}. The purpose of the Colours panel is to let you adjust the
\r
638 appearance of all the colours. So to change the colour of the
\r
639 cursor, for example, you would select \q{Cursor Colour}, press the
\r
640 \q{Modify} button, and select a new colour from the dialog box that
\r
641 appeared. Similarly, if you want your session to appear in green,
\r
642 you should select \q{Default Foreground} and press \q{Modify}.
\r
643 Clicking on \q{ANSI Green} won't turn your session green; it will
\r
644 only allow you to adjust the \e{shade} of green used when PuTTY is
\r
645 instructed by the server to display green text.
\r
647 \S{faq-winsock2}{Question} Plink on \i{Windows 95} says it can't find
\r
650 Plink requires the extended Windows network library, WinSock version
\r
651 2. This is installed as standard on Windows 98 and above, and on
\r
652 Windows NT, and even on later versions of Windows 95; but early
\r
653 Win95 installations don't have it.
\r
655 In order to use Plink on these systems, you will need to download
\r
657 \W{http://www.microsoft.com/windows95/downloads/contents/wuadmintools/s_wunetworkingtools/w95sockets2/}{WinSock 2 upgrade}:
\r
659 \c http://www.microsoft.com/windows95/downloads/contents/
\r
660 \c wuadmintools/s_wunetworkingtools/w95sockets2/
\r
662 \S{faq-outofmem}{Question} After trying to establish an SSH-2
\r
663 connection, PuTTY says \q{\ii{Out of memory}} and dies.
\r
665 If this happens just while the connection is starting up, this often
\r
666 indicates that for some reason the client and server have failed to
\r
667 establish a session encryption key. Somehow, they have performed
\r
668 calculations that should have given each of them the same key, but
\r
669 have ended up with different keys; so data encrypted by one and
\r
670 decrypted by the other looks like random garbage.
\r
672 This causes an \q{out of memory} error because the first encrypted
\r
673 data PuTTY expects to see is the length of an SSH message. Normally
\r
674 this will be something well under 100 bytes. If the decryption has
\r
675 failed, PuTTY will see a completely random length in the region of
\r
676 two \e{gigabytes}, and will try to allocate enough memory to store
\r
677 this non-existent message. This will immediately lead to it thinking
\r
678 it doesn't have enough memory, and panicking.
\r
680 If this happens to you, it is quite likely to still be a PuTTY bug
\r
681 and you should report it (although it might be a bug in your SSH
\r
682 server instead); but it doesn't necessarily mean you've actually run
\r
685 \S{faq-outofmem2}{Question} When attempting a file transfer, either
\r
686 PSCP or PSFTP says \q{\ii{Out of memory}} and dies.
\r
688 This is almost always caused by your \i{login scripts} on the server
\r
689 generating output. PSCP or PSFTP will receive that output when they
\r
690 were expecting to see the start of a file transfer protocol, and
\r
691 they will attempt to interpret the output as file-transfer protocol.
\r
692 This will usually lead to an \q{out of memory} error for much the
\r
693 same reasons as given in \k{faq-outofmem}.
\r
695 This is a setup problem in your account on your server, \e{not} a
\r
696 PSCP/PSFTP bug. Your login scripts should \e{never} generate output
\r
697 during non-interactive sessions; secure file transfer is not the
\r
698 only form of remote access that will break if they do.
\r
700 On Unix, a simple fix is to ensure that all the parts of your login
\r
701 script that might generate output are in \c{.profile} (if you use a
\r
702 Bourne shell derivative) or \c{.login} (if you use a C shell).
\r
703 Putting them in more general files such as \c{.bashrc} or \c{.cshrc}
\r
704 is liable to lead to problems.
\r
706 \S{faq-psftp-slow}{Question} PSFTP transfers files much slower than PSCP.
\r
708 The throughput of PSFTP 0.54 should be much better than 0.53b and
\r
709 prior; we've added code to the SFTP backend to queue several blocks
\r
710 of data rather than waiting for an acknowledgement for each. (The
\r
711 SCP backend did not suffer from this performance issue because SCP
\r
712 is a much simpler protocol.)
\r
714 \S{faq-bce}{Question} When I run full-colour applications, I see
\r
715 areas of black space where colour ought to be, or vice versa.
\r
717 You almost certainly need to change the \q{Use \i{background colour} to
\r
718 erase screen} setting in the Terminal panel. If there is too much
\r
719 black space (the commoner situation), you should enable it, while if
\r
720 there is too much colour, you should disable it. (See \k{config-erase}.)
\r
722 In old versions of PuTTY, this was disabled by default, and would not
\r
723 take effect until you reset the terminal (see \k{faq-resetterm}).
\r
724 Since 0.54, it is enabled by default, and changes take effect
\r
727 \S{faq-resetterm}{Question} When I change some terminal settings,
\r
730 Some of the terminal options (notably \ii{Auto Wrap} and
\r
731 background-colour screen erase) actually represent the \e{default}
\r
732 setting, rather than the currently active setting. The server can
\r
733 send sequences that modify these options in mid-session, but when
\r
734 the terminal is reset (by server action, or by you choosing \q{Reset
\r
735 Terminal} from the System menu) the defaults are restored.
\r
737 In versions 0.53b and prior, if you change one of these options in
\r
738 the middle of a session, you will find that the change does not
\r
739 immediately take effect. It will only take effect once you reset
\r
742 In version 0.54, the behaviour has changed - changes to these
\r
743 settings take effect immediately.
\r
745 \S{faq-idleout}{Question} My PuTTY sessions unexpectedly close after
\r
746 they are \I{idle connections}idle for a while.
\r
748 Some types of \i{firewall}, and almost any router doing Network Address
\r
749 Translation (\i{NAT}, also known as IP masquerading), will forget about
\r
750 a connection through them if the connection does nothing for too
\r
751 long. This will cause the connection to be rudely cut off when
\r
752 contact is resumed.
\r
754 You can try to combat this by telling PuTTY to send \e{keepalives}:
\r
755 packets of data which have no effect on the actual session, but
\r
756 which reassure the router or firewall that the network connection is
\r
757 still active and worth remembering about.
\r
759 Keepalives don't solve everything, unfortunately; although they
\r
760 cause greater robustness against this sort of router, they can also
\r
761 cause a \e{loss} of robustness against network dropouts. See
\r
762 \k{config-keepalive} in the documentation for more discussion of
\r
765 \S{faq-timeout}{Question} PuTTY's network connections time out too
\r
766 quickly when \I{breaks in connectivity}network connectivity is
\r
769 This is a Windows problem, not a PuTTY problem. The timeout value
\r
770 can't be set on per application or per session basis. To increase
\r
771 the TCP timeout globally, you need to tinker with the Registry.
\r
773 On Windows 95, 98 or ME, the registry key you need to create or
\r
776 \c HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\
\r
777 \c MSTCP\MaxDataRetries
\r
779 (it must be of type DWORD in Win95, or String in Win98/ME).
\r
780 (See MS Knowledge Base article
\r
781 \W{http://support.microsoft.com/default.aspx?scid=kb;en-us;158474}{158474}
\r
782 for more information.)
\r
784 On Windows NT, 2000, or XP, the registry key to create or change is
\r
786 \c HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
\r
787 \c Parameters\TcpMaxDataRetransmissions
\r
789 and it must be of type DWORD.
\r
790 (See MS Knowledge Base articles
\r
791 \W{http://support.microsoft.com/default.aspx?scid=kb;en-us;120642}{120642}
\r
793 \W{http://support.microsoft.com/default.aspx?scid=kb;en-us;314053}{314053}
\r
794 for more information.)
\r
796 Set the key's value to something like 10. This will cause Windows to
\r
797 try harder to keep connections alive instead of abandoning them.
\r
799 \S{faq-puttyputty}{Question} When I \cw{cat} a binary file, I get
\r
800 \q{PuTTYPuTTYPuTTY} on my command line.
\r
802 Don't do that, then.
\r
804 This is designed behaviour; when PuTTY receives the character
\r
805 Control-E from the remote server, it interprets it as a request to
\r
806 identify itself, and so it sends back the string \q{\cw{PuTTY}} as
\r
807 if that string had been entered at the keyboard. Control-E should
\r
808 only be sent by programs that are prepared to deal with the
\r
809 response. Writing a binary file to your terminal is likely to output
\r
810 many Control-E characters, and cause this behaviour. Don't do it.
\r
813 To mitigate the effects, you could configure the answerback string
\r
814 to be empty (see \k{config-answerback}); but writing binary files to
\r
815 your terminal is likely to cause various other unpleasant behaviour,
\r
816 so this is only a small remedy.
\r
818 \S{faq-wintitle}{Question} When I \cw{cat} a binary file, my \i{window
\r
819 title} changes to a nonsense string.
\r
821 Don't do that, then.
\r
823 It is designed behaviour that PuTTY should have the ability to
\r
824 adjust the window title on instructions from the server. Normally
\r
825 the control sequence that does this should only be sent
\r
826 deliberately, by programs that know what they are doing and intend
\r
827 to put meaningful text in the window title. Writing a binary file to
\r
828 your terminal runs the risk of sending the same control sequence by
\r
829 accident, and cause unexpected changes in the window title. Don't do
\r
832 \S{faq-password-fails}{Question} My \i{keyboard} stops working once
\r
833 PuTTY displays the \i{password prompt}.
\r
835 No, it doesn't. PuTTY just doesn't display the password you type, so
\r
836 that someone looking at your screen can't see what it is.
\r
838 Unlike the Windows login prompts, PuTTY doesn't display the password
\r
839 as a row of asterisks either. This is so that someone looking at
\r
840 your screen can't even tell how \e{long} your password is, which
\r
841 might be valuable information.
\r
843 \S{faq-keyboard}{Question} One or more \I{keyboard}\i{function keys}
\r
844 don't do what I expected in a server-side application.
\r
846 If you've already tried all the relevant options in the PuTTY
\r
847 Keyboard panel, you may need to mail the PuTTY maintainers and ask.
\r
849 It is \e{not} usually helpful just to tell us which application,
\r
850 which server operating system, and which key isn't working; in order
\r
851 to replicate the problem we would need to have a copy of every
\r
852 operating system, and every application, that anyone has ever
\r
855 PuTTY responds to function key presses by sending a sequence of
\r
856 control characters to the server. If a function key isn't doing what
\r
857 you expect, it's likely that the character sequence your application
\r
858 is expecting to receive is not the same as the one PuTTY is sending.
\r
859 Therefore what we really need to know is \e{what} sequence the
\r
860 application is expecting.
\r
862 The simplest way to investigate this is to find some other terminal
\r
863 environment, in which that function key \e{does} work; and then
\r
864 investigate what sequence the function key is sending in that
\r
865 situation. One reasonably easy way to do this on a \i{Unix} system is to
\r
866 type the command \i\c{cat}, and then press the function key. This is
\r
867 likely to produce output of the form \c{^[[11~}. You can also do
\r
868 this in PuTTY, to find out what sequence the function key is
\r
869 producing in that. Then you can mail the PuTTY maintainers and tell
\r
870 us \q{I wanted the F1 key to send \c{^[[11~}, but instead it's
\r
871 sending \c{^[OP}, can this be done?}, or something similar.
\r
873 You should still read the
\r
874 \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/feedback.html}{Feedback
\r
875 page} on the PuTTY website (also provided as \k{feedback} in the
\r
876 manual), and follow the guidelines contained in that.
\r
878 \S{faq-openssh-bad-openssl}{Question} Since my SSH server was upgraded
\r
879 to \i{OpenSSH} 3.1p1/3.4p1, I can no longer connect with PuTTY.
\r
881 There is a known problem when OpenSSH has been built against an
\r
882 incorrect version of OpenSSL; the quick workaround is to configure
\r
883 PuTTY to use SSH protocol 2 and the Blowfish cipher.
\r
885 For more details and OpenSSH patches, see
\r
886 \W{http://bugzilla.mindrot.org/show_bug.cgi?id=138}{bug 138} in the
\r
889 This is not a PuTTY-specific problem; if you try to connect with
\r
890 another client you'll likely have similar problems. (Although PuTTY's
\r
891 default cipher differs from many other clients.)
\r
893 \e{OpenSSH 3.1p1:} configurations known to be broken (and symptoms):
\r
895 \b SSH-2 with AES cipher (PuTTY says \q{Assertion failed! Expression:
\r
896 (len & 15) == 0} in \cw{sshaes.c}, or \q{Out of memory}, or crashes)
\r
898 \b SSH-2 with 3DES (PuTTY says \q{Incorrect MAC received on packet})
\r
900 \b SSH-1 with Blowfish (PuTTY says \q{Incorrect CRC received on
\r
905 \e{OpenSSH 3.4p1:} as of 3.4p1, only the problem with SSH-1 and
\r
906 Blowfish remains. Rebuild your server, apply the patch linked to from
\r
907 bug 138 above, or use another cipher (e.g., 3DES) instead.
\r
909 \e{Other versions:} we occasionally get reports of the same symptom
\r
910 and workarounds with older versions of OpenSSH, although it's not
\r
911 clear the underlying cause is the same.
\r
913 \S{faq-ssh2key-ssh1conn}{Question} Why do I see \q{Couldn't load
\r
914 private key from ...}? Why can PuTTYgen load my key but not PuTTY?
\r
916 It's likely that you've generated an SSH protocol 2 key with PuTTYgen,
\r
917 but you're trying to use it in an SSH-1 connection. SSH-1 and SSH-2 keys
\r
918 have different formats, and (at least in 0.52) PuTTY's reporting of a
\r
919 key in the wrong format isn't optimal.
\r
921 To connect using SSH-2 to a server that supports both versions, you
\r
922 need to change the configuration from the default (see \k{faq-ssh2}).
\r
924 \S{faq-rh8-utf8}{Question} When I'm connected to a \i{Red Hat Linux} 8.0
\r
925 system, some characters don't display properly.
\r
927 A common complaint is that hyphens in man pages show up as a-acute.
\r
929 With release 8.0, Red Hat appear to have made \i{UTF-8} the default
\r
930 character set. There appears to be no way for terminal emulators such
\r
931 as PuTTY to know this (as far as we know, the appropriate escape
\r
932 sequence to switch into UTF-8 mode isn't sent).
\r
934 A fix is to configure sessions to RH8 systems to use UTF-8
\r
935 translation - see \k{config-charset} in the documentation. (Note that
\r
936 if you use \q{Change Settings}, changes may not take place immediately
\r
937 - see \k{faq-resetterm}.)
\r
939 If you really want to change the character set used by the server, the
\r
940 right place is \c{/etc/sysconfig/i18n}, but this shouldn't be
\r
943 \S{faq-screen}{Question} Since I upgraded to PuTTY 0.54, the
\r
944 scrollback has stopped working when I run \c{screen}.
\r
946 PuTTY's terminal emulator has always had the policy that when the
\r
947 \q{\i{alternate screen}} is in use, nothing is added to the scrollback.
\r
948 This is because the usual sorts of programs which use the alternate
\r
949 screen are things like text editors, which tend to scroll back and
\r
950 forth in the same document a lot; so (a) they would fill up the
\r
951 scrollback with a large amount of unhelpfully disordered text, and
\r
952 (b) they contain their \e{own} method for the user to scroll back to
\r
953 the bit they were interested in. We have generally found this policy
\r
954 to do the Right Thing in almost all situations.
\r
956 Unfortunately, \c{screen} is one exception: it uses the alternate
\r
957 screen, but it's still usually helpful to have PuTTY's scrollback
\r
958 continue working. The simplest solution is to go to the Features
\r
959 control panel and tick \q{Disable switching to alternate terminal
\r
960 screen}. (See \k{config-features-altscreen} for more details.)
\r
961 Alternatively, you can tell \c{screen} itself not to use the
\r
962 alternate screen: the
\r
963 \W{http://www4.informatik.uni-erlangen.de/~jnweiger/screen-faq.html}{\c{screen}
\r
964 FAQ} suggests adding the line \cq{termcapinfo xterm ti@:te@} to your
\r
965 \cw{.screenrc} file.
\r
967 The reason why this only started to be a problem in 0.54 is because
\r
968 \c{screen} typically uses an unusual control sequence to switch to
\r
969 the alternate screen, and previous versions of PuTTY did not support
\r
972 \S{faq-alternate-localhost}{Question} Since I upgraded \i{Windows XP}
\r
973 to Service Pack 2, I can't use addresses like \cw{127.0.0.2}.
\r
975 Some people who ask PuTTY to listen on \i{localhost} addresses other
\r
976 than \cw{127.0.0.1} to forward services such as \i{SMB} and \i{Windows
\r
977 Terminal Services} have found that doing so no longer works since
\r
978 they upgraded to WinXP SP2.
\r
980 This is apparently an issue with SP2 that is acknowledged by Microsoft
\r
981 in MS Knowledge Base article
\r
982 \W{http://support.microsoft.com/default.aspx?scid=kb;en-us;884020}{884020}.
\r
983 The article links to a fix you can download.
\r
985 (\e{However}, we've been told that SP2 \e{also} fixes the bug that
\r
986 means you need to use non-\cw{127.0.0.1} addresses to forward
\r
987 Terminal Services in the first place.)
\r
989 \S{faq-missing-slash}{Question} PSFTP commands seem to be missing a
\r
990 directory separator (slash).
\r
992 Some people have reported the following incorrect behaviour with
\r
997 \c Remote directory is /dir1/dir2
\r
998 \c psftp> get filename.ext
\r
999 \e iiiiiiiiiiiiiiii
\r
1000 \c /dir1/dir2filename.ext: no such file or directory
\r
1002 This is not a bug in PSFTP. There is a known bug in some versions of
\r
1003 portable \i{OpenSSH}
\r
1004 (\W{http://bugzilla.mindrot.org/show_bug.cgi?id=697}{bug 697}) that
\r
1005 causes these symptoms; it appears to have been introduced around
\r
1006 3.7.x. It manifests only on certain platforms (AIX is what has been
\r
1009 There is a patch for OpenSSH attached to that bug; it's also fixed in
\r
1010 recent versions of portable OpenSSH (from around 3.8).
\r
1012 \S{faq-connaborted}{Question} Do you want to hear about \q{Software
\r
1013 caused connection abort}?
\r
1015 In the documentation for PuTTY 0.53 and 0.53b, we mentioned that we'd
\r
1016 like to hear about any occurrences of this error. Since the release
\r
1017 of PuTTY 0.54, however, we've been convinced that this error doesn't
\r
1018 indicate that PuTTY's doing anything wrong, and we don't need to hear
\r
1019 about further occurrences. See \k{errors-connaborted} for our current
\r
1020 documentation of this error.
\r
1022 \S{faq-rekey}{Question} My SSH-2 session \I{locking up, SSH-2
\r
1023 sessions}locks up for a few seconds every so often.
\r
1025 Recent versions of PuTTY automatically initiate \i{repeat key
\r
1026 exchange} once per hour, to improve session security. If your client
\r
1027 or server machine is slow, you may experience this as a delay of
\r
1028 anything up to thirty seconds or so.
\r
1030 These \I{delays, in SSH-2 sessions}delays are inconvenient, but they
\r
1031 are there for your protection. If they really cause you a problem,
\r
1032 you can choose to turn off periodic rekeying using the \q{Kex}
\r
1033 configuration panel (see \k{config-ssh-kex}), but be aware that you
\r
1034 will be sacrificing security for this. (Falling back to SSH-1 would
\r
1035 also remove the delays, but would lose a \e{lot} more security
\r
1036 still. We do not recommend it.)
\r
1038 \S{faq-xpwontrun}{Question} PuTTY fails to start up. Windows claims that
\r
1039 \q{the application configuration is incorrect}.
\r
1041 This is caused by a bug in certain versions of \i{Windows XP} which
\r
1042 is triggered by PuTTY 0.58. This was fixed in 0.59. The
\r
1043 \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/xp-wont-run}{\q{xp-wont-run}}
\r
1044 entry in PuTTY's wishlist has more details.
\r
1046 \H{faq-secure} Security questions
\r
1048 \S{faq-publicpc}{Question} Is it safe for me to download PuTTY and
\r
1049 use it on a public PC?
\r
1051 It depends on whether you trust that PC. If you don't trust the
\r
1052 public PC, don't use PuTTY on it, and don't use any other software
\r
1053 you plan to type passwords into either. It might be watching your
\r
1054 keystrokes, or it might tamper with the PuTTY binary you download.
\r
1055 There is \e{no} program safe enough that you can run it on an
\r
1056 actively malicious PC and get away with typing passwords into it.
\r
1058 If you do trust the PC, then it's probably OK to use PuTTY on it
\r
1059 (but if you don't trust the network, then the PuTTY download might
\r
1060 be tampered with, so it would be better to carry PuTTY with you on a
\r
1063 \S{faq-cleanup}{Question} What does PuTTY leave on a system? How can
\r
1064 I \i{clean up} after it?
\r
1066 PuTTY will leave some Registry entries, and a random seed file, on
\r
1067 the PC (see \k{faq-settings}). If you are using PuTTY on a public
\r
1068 PC, or somebody else's PC, you might want to clean these up when you
\r
1069 leave. You can do that automatically, by running the command
\r
1070 \c{putty -cleanup}. (Note that this only removes settings for
\r
1071 the currently logged-in user on \i{multi-user systems}.)
\r
1073 If PuTTY was installed from the installer package, it will also
\r
1074 appear in \q{Add/Remove Programs}. Older versions of the uninstaller
\r
1075 do not remove the above-mentioned registry entries and file.
\r
1077 \S{faq-dsa}{Question} How come PuTTY now supports \i{DSA}, when the
\r
1078 website used to say how insecure it was?
\r
1080 DSA has a major weakness \e{if badly implemented}: it relies on a
\r
1081 random number generator to far too great an extent. If the random
\r
1082 number generator produces a number an attacker can predict, the DSA
\r
1083 private key is exposed - meaning that the attacker can log in as you
\r
1084 on all systems that accept that key.
\r
1086 The PuTTY policy changed because the developers were informed of
\r
1087 ways to implement DSA which do not suffer nearly as badly from this
\r
1088 weakness, and indeed which don't need to rely on random numbers at
\r
1089 all. For this reason we now believe PuTTY's DSA implementation is
\r
1090 probably OK. However, if you have the choice, we still recommend you
\r
1093 \S{faq-virtuallock}{Question} Couldn't Pageant use
\r
1094 \cw{VirtualLock()} to stop private keys being written to disk?
\r
1096 Unfortunately not. The \cw{VirtualLock()} function in the Windows
\r
1097 API doesn't do a proper job: it may prevent small pieces of a
\r
1098 process's memory from being paged to disk while the process is
\r
1099 running, but it doesn't stop the process's memory as a whole from
\r
1100 being swapped completely out to disk when the process is long-term
\r
1101 inactive. And Pageant spends most of its time inactive.
\r
1103 \H{faq-admin} Administrative questions
\r
1105 \S{faq-domain}{Question} Would you like me to register you a nicer
\r
1108 No, thank you. Even if you can find one (most of them seem to have
\r
1109 been registered already, by people who didn't ask whether we
\r
1110 actually wanted it before they applied), we're happy with the PuTTY
\r
1111 web site being exactly where it is. It's not hard to find (just type
\r
1112 \q{putty} into \W{http://www.google.com/}{google.com} and we're the
\r
1113 first link returned), and we don't believe the administrative hassle
\r
1114 of moving the site would be worth the benefit.
\r
1116 In addition, if we \e{did} want a custom domain name, we would want
\r
1117 to run it ourselves, so we knew for certain that it would continue
\r
1118 to point where we wanted it, and wouldn't suddenly change or do
\r
1119 strange things. Having it registered for us by a third party who we
\r
1120 don't even know is not the best way to achieve this.
\r
1122 \S{faq-webhosting}{Question} Would you like free web hosting for the
\r
1125 We already have some, thanks.
\r
1127 \S{faq-link}{Question} Would you link to my web site from the PuTTY
\r
1130 Only if the content of your web page is of definite direct interest
\r
1131 to PuTTY users. If your content is unrelated, or only tangentially
\r
1132 related, to PuTTY, then the link would simply be advertising for
\r
1135 One very nice effect of the Google ranking mechanism is that by and
\r
1136 large, the most popular web sites get the highest rankings. This
\r
1137 means that when an ordinary person does a search, the top item in
\r
1138 the search is very likely to be a high-quality site or the site they
\r
1139 actually wanted, rather than the site which paid the most money for
\r
1142 The PuTTY web site is held in high esteem by Google, for precisely
\r
1143 this reason: lots of people have linked to it simply because they
\r
1144 like PuTTY, without us ever having to ask anyone to link to us. We
\r
1145 feel that it would be an abuse of this esteem to use it to boost the
\r
1146 ranking of random advertisers' web sites. If you want your web site
\r
1147 to have a high Google ranking, we'd prefer that you achieve this the
\r
1148 way we did - by being good enough at what you do that people will
\r
1149 link to you simply because they like you.
\r
1151 In particular, we aren't interested in trading links for money (see
\r
1152 above), and we \e{certainly} aren't interested in trading links for
\r
1153 other links (since we have no advertising on our web site, our
\r
1154 Google ranking is not even directly worth anything to us). If we
\r
1155 don't want to link to you for free, then we probably won't want to
\r
1156 link to you at all.
\r
1158 If you have software based on PuTTY, or specifically designed to
\r
1159 interoperate with PuTTY, or in some other way of genuine interest to
\r
1160 PuTTY users, then we will probably be happy to add a link to you on
\r
1161 our Links page. And if you're running a particularly valuable mirror
\r
1162 of the PuTTY web site, we might be interested in linking to you from
\r
1165 \S{faq-sourceforge}{Question} Why don't you move PuTTY to
\r
1168 Partly, because we don't want to move the web site location (see
\r
1171 Also, security reasons. PuTTY is a security product, and as such it
\r
1172 is particularly important to guard the code and the web site against
\r
1173 unauthorised modifications which might introduce subtle security
\r
1174 flaws. Therefore, we prefer that the Subversion repository, web site and
\r
1175 FTP site remain where they are, under the direct control of system
\r
1176 administrators we know and trust personally, rather than being run
\r
1177 by a large organisation full of people we've never met and which is
\r
1178 known to have had breakins in the past.
\r
1180 No offence to SourceForge; I think they do a wonderful job. But
\r
1181 they're not ideal for everyone, and in particular they're not ideal
\r
1184 \S{faq-mailinglist1}{Question} Why can't I subscribe to the
\r
1185 putty-bugs mailing list?
\r
1187 Because you're not a member of the PuTTY core development team. The
\r
1188 putty-bugs mailing list is not a general newsgroup-like discussion
\r
1189 forum; it's a contact address for the core developers, and an
\r
1190 \e{internal} mailing list for us to discuss things among ourselves.
\r
1191 If we opened it up for everybody to subscribe to, it would turn into
\r
1192 something more like a newsgroup and we would be completely
\r
1193 overwhelmed by the volume of traffic. It's hard enough to keep up
\r
1194 with the list as it is.
\r
1196 \S{faq-mailinglist2}{Question} If putty-bugs isn't a
\r
1197 general-subscription mailing list, what is?
\r
1199 There isn't one, that we know of.
\r
1201 If someone else wants to set up a mailing list or other forum for
\r
1202 PuTTY users to help each other with common problems, that would be
\r
1203 fine with us, though the PuTTY team would almost certainly not have the
\r
1204 time to read it. It's probably better to use one of the established
\r
1205 newsgroups for this purpose (see \k{feedback-other-fora}).
\r
1207 \S{faq-donations}{Question} How can I donate to PuTTY development?
\r
1209 Please, \e{please} don't feel you have to. PuTTY is completely free
\r
1210 software, and not shareware. We think it's very important that
\r
1211 \e{everybody} who wants to use PuTTY should be able to, whether they
\r
1212 have any money or not; so the last thing we would want is for a
\r
1213 PuTTY user to feel guilty because they haven't paid us any money. If
\r
1214 you want to keep your money, please do keep it. We wouldn't dream of
\r
1217 Having said all that, if you still really \e{want} to give us money,
\r
1218 we won't argue :-) The easiest way for us to accept donations is if
\r
1219 you send money to \cw{<anakin@pobox.com>} using PayPal
\r
1220 (\W{http://www.paypal.com/}\cw{www.paypal.com}). If you don't like
\r
1221 PayPal, talk to us; we can probably arrange some alternative means.
\r
1223 Small donations (tens of dollars or tens of euros) will probably be
\r
1224 spent on beer or curry, which helps motivate our volunteer team to
\r
1225 continue doing this for the world. Larger donations will be spent on
\r
1226 something that actually helps development, if we can find anything
\r
1227 (perhaps new hardware, or a copy of Windows XP), but if we can't
\r
1228 find anything then we'll just distribute the money among the
\r
1229 developers. If you want to be sure your donation is going towards
\r
1230 something worthwhile, ask us first. If you don't like these terms,
\r
1231 feel perfectly free not to donate. We don't mind.
\r
1233 \S{faq-permission}{Question} Can I have permission to put PuTTY on a
\r
1234 cover disk / distribute it with other software / etc?
\r
1236 Yes. For most things, you need not bother asking us explicitly for
\r
1237 permission; our licence already grants you permission.
\r
1239 See \k{feedback-permission} for more details.
\r
1241 \S{faq-indemnity}{Question} Can you sign an agreement indemnifying
\r
1242 us against security problems in PuTTY?
\r
1246 A vendor of physical security products (e.g. locks) might plausibly
\r
1247 be willing to accept financial liability for a product that failed
\r
1248 to perform as advertised and resulted in damage (e.g. valuables
\r
1249 being stolen). The reason they can afford to do this is because they
\r
1250 sell a \e{lot} of units, and only a small proportion of them will
\r
1251 fail; so they can meet their financial liability out of the income
\r
1252 from all the rest of their sales, and still have enough left over to
\r
1253 make a profit. Financial liability is intrinsically linked to
\r
1254 selling your product for money.
\r
1256 There are two reasons why PuTTY is not analogous to a physical lock
\r
1257 in this context. One is that software products don't exhibit random
\r
1258 variation: \e{if} PuTTY has a security hole (which does happen,
\r
1259 although we do our utmost to prevent it and to respond quickly when
\r
1260 it does), every copy of PuTTY will have the same hole, so it's
\r
1261 likely to affect all the users at the same time. So even if our
\r
1262 users were all paying us to use PuTTY, we wouldn't be able to
\r
1263 \e{simultaneously} pay every affected user compensation in excess of
\r
1264 the amount they had paid us in the first place. It just wouldn't
\r
1267 The second, much more important, reason is that PuTTY users
\r
1268 \e{don't} pay us. The PuTTY team does not have an income; it's a
\r
1269 volunteer effort composed of people spending their spare time to try
\r
1270 to write useful software. We aren't even a company or any kind of
\r
1271 legally recognised organisation. We're just a bunch of people who
\r
1272 happen to do some stuff in our spare time.
\r
1274 Therefore, to ask us to assume financial liability is to ask us to
\r
1275 assume a risk of having to pay it out of our own \e{personal}
\r
1276 pockets: out of the same budget from which we buy food and clothes
\r
1277 and pay our rent. That's more than we're willing to give. We're
\r
1278 already giving a lot of our spare \e{time} to developing software
\r
1279 for free; if we had to pay our own \e{money} to do it as well, we'd
\r
1280 start to wonder why we were bothering.
\r
1282 Free software fundamentally does not work on the basis of financial
\r
1283 guarantees. Your guarantee of the software functioning correctly is
\r
1284 simply that you have the source code and can check it before you use
\r
1285 it. If you want to be sure there aren't any security holes, do a
\r
1286 security audit of the PuTTY code, or hire a security engineer if you
\r
1287 don't have the necessary skills yourself: instead of trying to
\r
1288 ensure you can get compensation in the event of a disaster, try to
\r
1289 ensure there isn't a disaster in the first place.
\r
1291 If you \e{really} want financial security, see if you can find a
\r
1292 security engineer who will take financial responsibility for the
\r
1293 correctness of their review. (This might be less likely to suffer
\r
1294 from the everything-failing-at-once problem mentioned above, because
\r
1295 such an engineer would probably be reviewing a lot of \e{different}
\r
1296 products which would tend to fail independently.) Failing that, see
\r
1297 if you can persuade an insurance company to insure you against
\r
1298 security incidents, and if the insurer demands it as a condition
\r
1299 then get our code reviewed by a security engineer they're happy
\r
1302 \S{faq-permission-form}{Question} Can you sign this form granting us
\r
1303 permission to use/distribute PuTTY?
\r
1305 If your form contains any clause along the lines of \q{the
\r
1306 undersigned represents and warrants}, we're not going to sign it.
\r
1307 This is particularly true if it asks us to warrant that PuTTY is
\r
1308 secure; see \k{faq-indemnity} for more discussion of this. But it
\r
1309 doesn't really matter what we're supposed to be warranting: even if
\r
1310 it's something we already believe is true, such as that we don't
\r
1311 infringe any third-party copyright, we will not sign a document
\r
1312 accepting any legal or financial liability. This is simply because
\r
1313 the PuTTY development project has no income out of which to satisfy
\r
1314 that liability, or pay legal costs, should it become necessary. We
\r
1315 cannot afford to be sued. We are assuring you that \e{we have done
\r
1316 our best}; if that isn't good enough for you, tough.
\r
1318 The existing PuTTY licence document already gives you permission to
\r
1319 use or distribute PuTTY in pretty much any way which does not
\r
1320 involve pretending you wrote it or suing us if it goes wrong. We
\r
1321 think that really ought to be enough for anybody.
\r
1323 See also \k{faq-permission-general} for another reason why we don't
\r
1324 want to do this sort of thing.
\r
1326 \S{faq-permission-future}{Question} Can you write us a formal notice
\r
1327 of permission to use PuTTY?
\r
1329 We could, in principle, but it isn't clear what use it would be. If
\r
1330 you think there's a serious chance of one of the PuTTY copyright
\r
1331 holders suing you (which we don't!), you would presumably want a
\r
1332 signed notice from \e{all} of them; and we couldn't provide that
\r
1333 even if we wanted to, because many of the copyright holders are
\r
1334 people who contributed some code in the past and with whom we
\r
1335 subsequently lost contact. Therefore the best we would be able to do
\r
1336 \e{even in theory} would be to have the core development team sign
\r
1337 the document, which wouldn't guarantee you that some other copyright
\r
1338 holder might not sue.
\r
1340 See also \k{faq-permission-general} for another reason why we don't
\r
1341 want to do this sort of thing.
\r
1343 \S{faq-permission-general}{Question} Can you sign \e{anything} for
\r
1346 Not unless there's an incredibly good reason.
\r
1348 We are generally unwilling to set a precedent that involves us
\r
1349 having to enter into individual agreements with PuTTY users. We
\r
1350 estimate that we have literally \e{millions} of users, and we
\r
1351 absolutely would not have time to go round signing specific
\r
1352 agreements with every one of them. So if you want us to sign
\r
1353 something specific for you, you might usefully stop to consider
\r
1354 whether there's anything special that distinguishes you from 999,999
\r
1355 other users, and therefore any reason we should be willing to sign
\r
1356 something for you without it setting such a precedent.
\r
1358 If your company policy requires you to have an individual agreement
\r
1359 with the supplier of any software you use, then your company policy
\r
1360 is simply not well suited to using popular free software, and we
\r
1361 urge you to consider this as a flaw in your policy.
\r
1363 \S{faq-permission-assurance}{Question} If you won't sign anything,
\r
1364 can you give us some sort of assurance that you won't make PuTTY
\r
1365 closed-source in future?
\r
1369 If what you want is an assurance that some \e{current version} of
\r
1370 PuTTY which you've already downloaded will remain free, then you
\r
1371 already have that assurance: it's called the PuTTY Licence. It
\r
1372 grants you permission to use, distribute and copy the software to
\r
1373 which it applies; once we've granted that permission (which we
\r
1374 have), we can't just revoke it.
\r
1376 On the other hand, if you want an assurance that \e{future} versions
\r
1377 of PuTTY won't be closed-source, that's more difficult. We could in
\r
1378 principle sign a document stating that we would never release a
\r
1379 closed-source PuTTY, but that wouldn't assure you that we \e{would}
\r
1380 keep releasing \e{open}-source PuTTYs: we would still have the
\r
1381 option of ceasing to develop PuTTY at all, which would surely be
\r
1382 even worse for you than making it closed-source! (And we almost
\r
1383 certainly wouldn't \e{want} to sign a document guaranteeing that we
\r
1384 would actually continue to do development work on PuTTY; we
\r
1385 certainly wouldn't sign it for free. Documents like that are called
\r
1386 contracts of employment, and are generally not signed except in
\r
1387 return for a sizeable salary.)
\r
1389 If we \e{were} to stop developing PuTTY, or to decide to make all
\r
1390 future releases closed-source, then you would still be free to copy
\r
1391 the last open release in accordance with the current licence, and in
\r
1392 particular you could start your own fork of the project from that
\r
1393 release. If this happened, I confidently predict that \e{somebody}
\r
1394 would do that, and that some kind of a free PuTTY would continue to
\r
1395 be developed. There's already precedent for that sort of thing
\r
1396 happening in free software. We can't guarantee that somebody
\r
1397 \e{other than you} would do it, of course; you might have to do it
\r
1398 yourself. But we can assure you that there would be nothing
\r
1399 \e{preventing} anyone from continuing free development if we
\r
1402 (Finally, we can also confidently predict that if we made PuTTY
\r
1403 closed-source and someone made an open-source fork, most people
\r
1404 would switch to the latter. Therefore, it would be pretty stupid of
\r
1407 \S{faq-export-cert}{Question} Can you provide us with export control
\r
1408 information / FIPS certification for PuTTY?
\r
1410 Some people have asked us for an Export Control Classification Number
\r
1411 (ECCN) for PuTTY. We don't know whether we have one, and as a team of
\r
1412 free software developers based in the UK we don't have the time,
\r
1413 money, or effort to deal with US bureaucracy to investigate any
\r
1414 further. We believe that PuTTY falls under 5D002 on the US Commerce
\r
1415 Control List, but that shouldn't be taken as definitive. If you need
\r
1416 to know more you should seek professional legal advice. The same
\r
1417 applies to any other country's legal requirements and restrictions.
\r
1419 Similarly, some people have asked us for FIPS certification of the
\r
1420 PuTTY tools. Unless someone else is prepared to do the necessary work
\r
1421 and pay any costs, we can't provide this.
\r
1423 \H{faq-misc} Miscellaneous questions
\r
1425 \S{faq-openssh}{Question} Is PuTTY a port of \i{OpenSSH}, or based on
\r
1426 OpenSSH or OpenSSL?
\r
1428 No, it isn't. PuTTY is almost completely composed of code written
\r
1429 from scratch for PuTTY. The only code we share with OpenSSH is the
\r
1430 detector for SSH-1 CRC compensation attacks, written by CORE SDI
\r
1431 S.A; we share no code at all with OpenSSL.
\r
1433 \S{faq-sillyputty}{Question} Where can I buy silly putty?
\r
1435 You're looking at the wrong web site; the only PuTTY we know about
\r
1436 here is the name of a computer program.
\r
1438 If you want the kind of putty you can buy as an executive toy, the
\r
1439 PuTTY team can personally recommend Thinking Putty, which you can
\r
1440 buy from Crazy Aaron's Putty World, at
\r
1441 \W{http://www.puttyworld.com}\cw{www.puttyworld.com}.
\r
1443 \S{faq-meaning}{Question} What does \q{PuTTY} mean?
\r
1445 It's the name of a popular SSH and Telnet client. Any other meaning
\r
1446 is in the eye of the beholder. It's been rumoured that \q{PuTTY}
\r
1447 is the antonym of \q{\cw{getty}}, or that it's the stuff that makes your
\r
1448 Windows useful, or that it's a kind of plutonium Teletype. We
\r
1449 couldn't possibly comment on such allegations.
\r
1451 \S{faq-pronounce}{Question} How do I pronounce \q{PuTTY}?
\r
1453 Exactly like the English word \q{putty}, which we pronounce
\r
1454 /\u02C8{'}p\u028C{V}ti/.
\r
OSDN Git Service
