ee46ef84 |
1 | \A{faq} PuTTY FAQ |
2 | |
3 | This FAQ is published on the PuTTY web site, and also provided as an |
4 | appendix in the manual. |
5 | |
6 | \H{faq-support} Features supported in PuTTY |
7 | |
8 | In general, if you want to know if PuTTY supports a particular |
9 | feature, you should look for it on the |
10 | \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/}{PuTTY web site}. |
11 | In particular: |
12 | |
13 | \b try the |
14 | \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html}{changes |
15 | page}, and see if you can find the feature on there. If a feature is |
16 | listed there, it's been implemented. If it's listed as a change made |
17 | \e{since} the latest version, it should be available in the |
18 | development snapshots, in which case testing will be very welcome. |
19 | |
20 | \b try the |
21 | \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist.html}{Wishlist |
22 | page}, and see if you can find the feature there. If it's on there, |
23 | it probably \e{hasn't} been implemented. |
24 | |
70706890 |
25 | \S{faq-ssh2}{question} Does PuTTY support SSH v2? |
ee46ef84 |
26 | |
27 | Yes. SSH v2 support has been available in PuTTY since version 0.50. |
28 | However, currently the \e{default} SSH protocol is v1; to select SSH |
29 | v2 if your server supports both, go to the SSH panel and change the |
30 | \e{Preferred SSH protocol version} option. |
31 | |
32 | Public key authentication (both RSA and DSA) in SSH v2 has been |
33 | added since version 0.51. |
34 | |
70706890 |
35 | \S{faq-ssh2-keyfmt}{question} Does PuTTY support reading OpenSSH or |
ee46ef84 |
36 | \cw{ssh.com} SSHv2 private key files? |
37 | |
38 | Not at present. OpenSSH and \cw{ssh.com} have totally different |
39 | formats for private key files, and neither one is particularly |
40 | pleasant, so PuTTY has its own. We do plan to write a converter at |
41 | some stage. |
42 | |
70706890 |
43 | \S{faq-ssh1}{question} Does PuTTY support SSH v1? |
ee46ef84 |
44 | |
45 | Yes. SSH 1 support has always been available in PuTTY. |
46 | |
70706890 |
47 | \S{faq-localecho}{question} Does PuTTY support local echo? |
ee46ef84 |
48 | |
49 | Yes. |
50 | |
51 | In version 0.51 and before, local echo cannot be separated from |
52 | local line editing (where you type a line of text locally, and it is |
53 | not sent to the server until you press Return, so you have the |
54 | chance to edit it and correct mistakes \e{before} the server sees |
55 | it). The two features can be enabled and disabled from the Terminal |
56 | panel, using the checkbox marked \q{Use local terminal line |
57 | discipline}. Note that due to a bug in those versions of PuTTY, |
58 | changing this feature in mid-session will have no effect; you have |
59 | to enable it \e{before} you open the connection. |
60 | |
61 | In later versions, local echo and local line editing are separate |
62 | options, and by default PuTTY will try to determine automatically |
63 | whether to enable them or not, based on which protocol you have |
64 | selected and also based on hints from the server. If you have a |
65 | problem with PuTTY's default choice, you can force each option to be |
66 | enabled or disabled as you choose. The controls are in the Terminal |
67 | panel, in the section marked \q{Line discipline options}. |
68 | |
70706890 |
69 | \S{faq-disksettings}{question} Does PuTTY support storing its |
70 | settings in a disk file? |
ee46ef84 |
71 | |
72 | Not at present, although \k{config-file} in the documentation gives |
73 | a method of achieving the same effect. |
74 | |
70706890 |
75 | \S{faq-fullscreen}{question} Does PuTTY support full-screen mode, |
76 | like a DOS box? |
ee46ef84 |
77 | |
78 | Not in the 0.51 release, but it has been added since then. |
79 | |
70706890 |
80 | \S{faq-password}{question} Does PuTTY have the ability to remember |
81 | my password so I don't have to type it every time? |
ee46ef84 |
82 | |
83 | No, it doesn't. |
84 | |
85 | Remembering your password is a bad plan for obvious security |
86 | reasons: anyone who gains access to your machine while you're away |
87 | from your desk can find out the remembered password, and use it, |
88 | abuse it or change it. |
89 | |
90 | In addition, it's not even \e{possible} for PuTTY to automatically |
91 | send your password in a Telnet session, because Telnet doesn't give |
92 | the client software any indication of which part of the login |
93 | process is the password prompt. PuTTY would have to guess, by |
94 | looking for words like \q{password} in the session data; and if your |
95 | login program is written in something other than English, this won't |
96 | work. |
97 | |
98 | In SSH, remembering your password would be possible in theory, but |
99 | there doesn't seem to be much point since SSH supports public key |
100 | authentication, which is more flexible and more secure. See |
101 | \k{pubkey} in the documentation for a full discussion of public key |
102 | authentication. |
103 | |
70706890 |
104 | \S{faq-hostkeys}{question} Is there an option to turn off the |
105 | annoying host key prompts? |
cad566a9 |
106 | |
107 | No, there isn't. And there won't be. Even if you write it yourself |
108 | and send us the patch, we won't accept it. |
109 | |
110 | Those annoying host key prompts are the \e{whole point} of SSH. |
111 | Without them, all the cryptographic technology SSH uses to secure |
112 | your session is doing nothing more than making an attacker's job |
113 | slightly harder; instead of sitting between you and the server with |
114 | a packet sniffer, the attacker must actually subvert a router and |
115 | start modifying the packets going back and forth. But that's not all |
116 | that much harder than just sniffing; and without host key checking, |
117 | it will go completely undetected by client or server. |
118 | |
119 | Host key checking is your guarantee that the encryption you put on |
120 | your data at the client end is the \e{same} encryption taken off the |
121 | data at the server end; it's your guarantee that it hasn't been |
122 | removed and replaced somewhere on the way. Host key checking makes |
123 | the attacker's job \e{astronomically} hard, compared to packet |
124 | sniffing, and even compared to subverting a router. Instead of |
125 | applying a little intelligence and keeping an eye on Bugtraq, the |
126 | attacker must now perform a brute-force attack against at least one |
127 | military-strength cipher. That insignificant host key prompt really |
128 | does make \e{that} much difference. |
129 | |
130 | If you're having a specific problem with host key checking - perhaps |
131 | you want an automated batch job to make use of PSCP or Plink, and |
132 | the interactive host key prompt is hanging the batch process - then |
133 | the right way to fix it is to add the correct host key to the |
134 | Registry in advance. That way, you retain the \e{important} feature |
135 | of host key checking: the right key will be accepted and the wrong |
136 | ones will not. Adding an option to turn host key checking off |
137 | completely is the wrong solution and we will not do it. |
138 | |
70706890 |
139 | \S{faq-server}{question} Will you write an SSH server for the PuTTY |
140 | suite, to go with the client? |
ae915483 |
141 | |
142 | No. The only reason we might want to would be if we could easily |
143 | re-use existing code and significantly cut down the effort. We don't |
144 | believe this is the case; there just isn't enough common ground |
145 | between an SSH client and server to make it worthwhile. |
146 | |
147 | If someone else wants to use bits of PuTTY in the process of writing |
148 | a Windows SSH server, they'd be perfectly welcome to of course, but |
149 | I really can't see it being a lot less effort for us to do that than |
150 | it would be for us to write a server from the ground up. We don't |
151 | have time, and we don't have motivation. The code is available if |
152 | anyone else wants to try it. |
153 | |
ee46ef84 |
154 | \H{faq-ports} Ports to other operating systems |
155 | |
156 | The eventual goal is for PuTTY to be a multi-platform program, able |
157 | to run on at least Windows, MacOS and Unix. Whether this will |
158 | actually ever happen I have no idea, but it is the plan. A Mac port |
159 | has been started, but is only half-finished and currently not moving |
160 | very fast. |
161 | |
162 | Porting will become easier once PuTTY has a generalised porting |
163 | layer, drawing a clear line between platform-dependent and |
164 | platform-independent code. The general intention is for this porting |
165 | layer to evolve naturally as part of the process of doing the first |
166 | port. One particularly nasty part of this will be separating the |
167 | many configuration options into platform-dependent and |
168 | platform-independent ones; for example, the options controlling when |
169 | the Windows System menu appears will be pretty much meaningless |
170 | under X11 or perhaps other windowing systems, whereas Telnet Passive |
171 | Mode is universal and shouldn't need to be specified once for each |
172 | platform. |
173 | |
70706890 |
174 | \S{faq-wince}{question} Will there be a port to Windows CE? |
ee46ef84 |
175 | |
176 | Probably not in the particularly near future. Despite sharing large |
177 | parts of the Windows API, in practice WinCE doesn't appear to be |
178 | significantly easier to port to than a totally different operating |
179 | system. |
180 | |
181 | However, PuTTY on portable devices would clearly be a useful thing, |
182 | so in the long term I hope there will be a WinCE port. |
183 | |
70706890 |
184 | \S{faq-mac}{question} Will there be a port to the Mac? |
ee46ef84 |
185 | |
186 | A Mac port was started once and is half-finished, but development |
187 | has been static for some time and the main PuTTY code has moved on, |
188 | so it's not clear how quickly development would resume even if |
189 | developer effort were available. |
190 | |
70706890 |
191 | \S{faq-unix}{question} Will there be a port to Unix? |
ee46ef84 |
192 | |
193 | I hope so, if only so that I can have an \cw{xterm}-like program |
194 | that supports exactly the same terminal emulation as PuTTY. If and |
195 | when we do do a Unix port, it will have a local-terminal back end so |
196 | it can be used like an \cw{xterm}, rather than only being usable as |
197 | a network utility. |
198 | |
70706890 |
199 | \S{faq-epoc}{question} Will there be a port to EPOC? |
ee46ef84 |
200 | |
201 | I hope so, but given that ports aren't really progressing very fast |
202 | even on systems the developers \e{do} already know how to program |
203 | for, it might be a long time before any of us get round to learning |
204 | a new system and doing the port for that. |
205 | |
206 | \H{faq-embedding} Embedding PuTTY in other programs |
207 | |
70706890 |
208 | \S{faq-dll}{question} Is the SSH or Telnet code available as a DLL? |
ee46ef84 |
209 | |
210 | No, it isn't. It would take a reasonable amount of rewriting for |
211 | this to be possible, and since the PuTTY project itself doesn't |
212 | believe in DLLs (they make installation more error-prone) none of us |
213 | has taken the time to do it. |
214 | |
215 | Most of the code cleanup work would be a good thing to happen in |
216 | general, so if anyone feels like helping, we wouldn't say no. |
217 | |
70706890 |
218 | \S{faq-vb}{question} Is the SSH or Telnet code available as a Visual |
219 | Basic component? |
ee46ef84 |
220 | |
221 | No, it isn't. None of the PuTTY team uses Visual Basic, and none of |
222 | us has any particular need to make SSH connections from a Visual |
223 | Basic application. In addition, all the preliminary work to turn it |
224 | into a DLL would be necessary first; and furthermore, we don't even |
225 | know how to write VB components. |
226 | |
227 | If someone offers to do some of this work for us, we might consider |
228 | it, but unless that happens I can't see VB integration being |
229 | anywhere other than the very bottom of our priority list. |
230 | |
70706890 |
231 | \S{faq-ipc}{question} How can I use PuTTY to make an SSH connection |
232 | from within another program? |
ee46ef84 |
233 | |
234 | Probably your best bet is to use Plink, the command-line connection |
235 | tool. If you can start Plink as a second Windows process, and |
236 | arrange for your primary process to be able to send data to the |
237 | Plink process, and receive data from it, through pipes, then you |
238 | should be able to make SSH connections from your program. |
239 | |
240 | This is what CVS for Windows does, for example. |
241 | |
242 | \H{faq-details} Details of PuTTY's operation |
243 | |
70706890 |
244 | \S{faq-term}{question} What terminal type does PuTTY use? |
ee46ef84 |
245 | |
246 | For most purposes, PuTTY can be considered to be an \cw{xterm} |
247 | terminal, although full support for some of \cw{xterm}'s features, |
248 | such as passing mouse actions to the server-side program, is not |
249 | present in the 0.51 release (but has been added since). |
250 | |
251 | PuTTY also supports some terminal control sequences not supported by |
252 | the real \cw{xterm}: notably the Linux console sequences that |
253 | reconfigure the colour palette, and the title bar control sequences |
254 | used by \cw{DECterm} (which are different from the \cw{xterm} ones; |
255 | PuTTY supports both). |
256 | |
257 | By default, PuTTY announces its terminal type to the server as |
258 | \c{xterm}. If you have a problem with this, you can reconfigure it |
259 | to say something else; \c{vt220} might help if you have trouble. |
260 | |
70706890 |
261 | \S{faq-settings}{question} Where does PuTTY store its data? |
ee46ef84 |
262 | |
263 | PuTTY stores most of its data (saved sessions, SSH host keys) in the |
264 | Registry. The precise location is |
265 | |
266 | \c HKEY_CURRENT_USER\Software\SimonTatham\PuTTY |
267 | |
268 | and within that area, saved sessions are stored under \c{Sessions} |
269 | while host keys are stored under \c{SshHostKeys}. |
270 | |
271 | PuTTY also requires a random number seed file, to improve the |
272 | unpredictability of randomly chosen data needed as part of the SSH |
273 | cryptography. This is stored by default in your Windows home |
274 | directory (\c{%HOMEDRIVE%\\%HOMEPATH%}), or in the actual Windows |
275 | directory (such as \c{C:\\WINDOWS}) if the home directory doesn't |
276 | exist, for example if you're using Win95. If you want to change the |
277 | location of the random number seed file, you can put your chosen |
278 | pathname in the Registry, at |
279 | |
280 | \c HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\RandSeedFile |
281 | |
282 | \H{faq-howto} HOWTO questions |
283 | |
70706890 |
284 | \S{faq-startmax}{question} How can I make PuTTY start up maximised? |
ee46ef84 |
285 | |
286 | Create a Windows shortcut to start PuTTY from, and set it as \q{Run |
287 | Maximized}. |
288 | |
70706890 |
289 | \S{faq-startsess}{question} How can I create a Windows shortcut to |
290 | start a particular saved session directly? |
ee46ef84 |
291 | |
292 | To run a PuTTY session saved under the name \q{\cw{mysession}}, |
293 | create a Windows shortcut that invokes PuTTY with a command line |
294 | like |
295 | |
296 | \c \path\name\to\putty.exe @mysession |
297 | |
70706890 |
298 | \S{faq-startssh}{question} How can I start an SSH session straight |
299 | from the command line? |
ee46ef84 |
300 | |
301 | Use the command line \c{putty -ssh host.name}. Alternatively, create |
302 | a saved session that specifies the SSH protocol, and start the saved |
303 | session as shown in \k{faq-startsess}. |
304 | |
70706890 |
305 | \S{faq-cutpaste}{question} How do I copy and paste between PuTTY and |
306 | other Windows applications? |
ee46ef84 |
307 | |
308 | Copy and paste works similarly to the X Window System. You use the |
309 | left mouse button to select text in the PuTTY window. The act of |
310 | selection \e{automatically} copies the text to the clipboard: there |
311 | is no need to press Ctrl-Ins or Ctrl-C or anything else. In fact, |
312 | pressing Ctrl-C will send a Ctrl-C character to the other end of |
313 | your connection (just like it does the rest of the time), which may |
314 | have unpleasant effects. The \e{only} thing you need to do, to copy |
315 | text to the clipboard, is to select it. |
316 | |
317 | To paste the clipboard contents into a PuTTY window, by default you |
318 | click the right mouse button. If you have a three-button mouse and |
319 | are used to X applications, you can configure pasting to be done by |
320 | the middle button instead, but this is not the default because most |
321 | Windows users don't have a middle button at all. |
322 | |
323 | You can also paste by pressing Shift-Ins. |
324 | |
70706890 |
325 | \S{faq-tunnels}{question} How do I use X forwarding and port |
326 | forwarding? I can't find the Tunnels panel. |
f2003e32 |
327 | |
328 | If you're looking in the 0.51 release or earlier, the Tunnels panel |
329 | isn't there. It was added in the development snapshots after 0.51, |
330 | and releases 0.52 and onwards will contain it. |
331 | |
70706890 |
332 | \S{faq-options}{question} How do I use all PuTTY's features (public |
333 | keys, port forwarding, SSH v2, etc.) in PSCP, PSFTP and Plink? |
72be5b5e |
334 | |
335 | The command-line tools are currently rather short of command line |
336 | options to enable this sort of thing. However, you can use most of |
337 | PuTTY's features if you create a PuTTY saved session, and then use |
338 | the name of the saved session on the command line in place of a |
339 | hostname. This works for PSCP, PSFTP and Plink (but don't expect |
340 | port forwarding in the file transfer applications!). |
f2003e32 |
341 | |
70706890 |
342 | \S{faq-pscp}{question} How do I use PSCP.EXE? When I double-click it |
343 | gives me a command prompt window which then closes instantly. |
ee46ef84 |
344 | |
345 | PSCP is a command-line application, not a GUI application. If you |
346 | run it without arguments, it will simply print a help message and |
347 | terminate. |
348 | |
349 | To use PSCP properly, run it from a Command Prompt window. See |
350 | \k{pscp} in the documentation for more details. |
351 | |
70706890 |
352 | \S{faq-pscp-spaces}{question} How do I use PSCP to copy a file whose |
353 | name has spaces in? |
ee46ef84 |
354 | |
355 | If PSCP is using the traditional SCP protocol, this is confusing. If |
356 | you're specifying a file at the local end, you just use one set of |
357 | quotes as you would normally do: |
358 | |
359 | \c pscp "local filename with spaces" user@host: |
360 | \c pscp user@host:myfile "local filename with spaces" |
361 | |
362 | But if the filename you're specifying is on the \e{remote} side, you |
363 | have to use backslashes and two sets of quotes: |
364 | |
365 | \c pscp user@host:"\"remote filename with spaces\"" local_filename |
366 | \c pscp local_filename user@host:"\"remote filename with spaces\"" |
367 | |
368 | Worse still, in a remote-to-local copy you have to specify the local |
369 | file name explicitly, otherwise PSCP will complain that they don't |
370 | match (unless you specified the \c{-unsafe} option). The following |
371 | command will give an error message: |
372 | |
373 | \c c:\>pscp user@host:"\"oo er\"" . |
e9cee352 |
374 | \c warning: remote host tried to write to a file called 'oo er' |
375 | \c when we requested a file called '"oo er"'. |
ee46ef84 |
376 | |
e9cee352 |
377 | Instead, you need to specify the local file name in full: |
378 | |
379 | \c c:\>pscp user@host:"\"oo er\"" "oo er" |
380 | |
ee46ef84 |
381 | If PSCP is using the newer SFTP protocol, none of this is a problem, |
382 | and all filenames with spaces in are specified using a single pair |
383 | of quotes in the obvious way: |
384 | |
385 | \c pscp "local file" user@host: |
386 | \c pscp user@host:"remote file" . |
387 | |
388 | \H{faq-trouble} Troubleshooting |
389 | |
70706890 |
390 | \S{faq-mac}{question} Why do I see \q{Incorrect MAC received on |
391 | packet}? |
ee46ef84 |
392 | |
393 | This is due to a bug in old SSH 2 servers distributed by |
394 | \cw{ssh.com}. Version 2.3.0 and below of their SSH 2 server |
395 | constructs Message Authentication Codes in the wrong way, and |
396 | expects the client to construct them in the same wrong way. PuTTY |
397 | constructs the MACs correctly by default, and hence these old |
398 | servers will fail to work with it. |
399 | |
400 | If you are using PuTTY version 0.51 or below, go to the SSH panel |
401 | and check the box labelled \q{Imitate SSH 2 MAC bug}. This will |
402 | cause PuTTY to construct its MACs in the same incorrect manner as |
403 | the buggy servers, so it will be able to work with them. |
404 | |
405 | Since version 0.51, PuTTY has been enhanced to detect buggy servers |
406 | automatically (when they announce their version) and enable the |
407 | workaround without the user needing to ask. Therefore you \e{should} |
408 | never have to use this option again after 0.52, but it is still |
409 | provided just in case another buggy server shows up. |
410 | |
b7e2c163 |
411 | In this context MAC stands for Message Authentication Code. It's a |
412 | cryptographic term, and it has nothing at all to do with Ethernet |
413 | MAC (Media Access Control) addresses. |
414 | |
70706890 |
415 | \S{faq-colours}{question} I clicked on a colour in the Colours |
416 | panel, and the colour didn't change in my terminal. |
ee46ef84 |
417 | |
418 | That isn't how you're supposed to use the Colours panel. |
419 | |
420 | During the course of a session, PuTTY potentially uses \e{all} the |
421 | colours listed in the Colours panel. It's not a question of using |
422 | only one of them and you choosing which one; PuTTY will use them |
423 | \e{all}. The purpose of the Colours panel is to let you adjust the |
424 | appearance of all the colours. So to change the colour of the |
425 | cursor, for example, you would select \q{Cursor Colour}, press the |
426 | \q{Modify} button, and select a new colour from the dialog box that |
427 | appeared. Similarly, if you want your session to appear in green, |
428 | you should select \q{Default Foreground} and press \q{Modify}. |
429 | Clicking on \q{ANSI Green} won't turn your session green; it will |
430 | only allow you to adjust the \e{shade} of green used when PuTTY is |
431 | instructed by the server to display green text. |
432 | |
70706890 |
433 | \S{faq-winsock2}{question} Plink on Windows 95 says it can't find |
434 | \cw{WS2_32.DLL}. |
ee46ef84 |
435 | |
436 | Plink requires the extended Windows network library, WinSock version |
437 | 2. This is installed as standard on Windows 98 and above, and on |
438 | Windows NT, and even on later versions of Windows 95; but early |
439 | Win95 installations don't have it. |
440 | |
441 | In order to use Plink on these systems, you will need to download |
442 | the |
443 | \W{http://www.microsoft.com/windows95/downloads/contents/wuadmintools/s_wunetworkingtools/w95sockets2/}{WinSock 2 upgrade}: |
444 | |
445 | \c http://www.microsoft.com/windows95/downloads/contents/wuadmintools/ |
446 | \c s_wunetworkingtools/w95sockets2/ |
447 | |
70706890 |
448 | \S{faq-rekey}{question} My PuTTY sessions close after an hour and |
449 | tell me \q{Server failed host key check}. |
ee46ef84 |
450 | |
451 | This is a bug in all versions of PuTTY up to and including 0.51. SSH |
452 | v2 servers from \cw{ssh.com} will require the key exchange to be |
453 | repeated one hour after the start of the connection, and PuTTY will |
454 | get this wrong. |
455 | |
456 | The bug has been fixed since version 0.51, so upgrading to a later |
457 | version or snapshot should solve the problem. |
458 | |
70706890 |
459 | \S{faq-outofmem}{question} After trying to establish an SSH 2 |
460 | connection, PuTTY says \q{Out of memory} and dies. |
ee46ef84 |
461 | |
462 | If this happens just while the connection is starting up, this often |
463 | indicates that for some reason the client and server have failed to |
464 | establish a session encryption key. Somehow, they have performed |
465 | calculations that should have given each of them the same key, but |
466 | have ended up with different keys; so data encrypted by one and |
467 | decrypted by the other looks like random garbage. |
468 | |
469 | This causes an \q{out of memory} error because the first encrypted |
470 | data PuTTY expects to see is the length of an SSH message. Normally |
471 | this will be something well under 100 bytes. If the decryption has |
472 | failed, PuTTY will see a completely random length in the region of |
473 | two \e{gigabytes}, and will try to allocate enough memory to store |
474 | this non-existent message. This will immediately lead to it thinking |
475 | it doesn't have enough memory, and panicking. |
476 | |
477 | If this happens to you, it is quite likely to still be a PuTTY bug |
478 | and you should report it (although it might be a bug in your SSH |
479 | server instead); but it doesn't necessarily mean you've actually run |
480 | out of memory. |
481 | |
70706890 |
482 | \S{faq-bce}{question} When I run full-colour applications, I see |
483 | areas of black space where colour ought to be. |
f1453e5c |
484 | |
485 | You almost certainly need to enable the \q{Use background colour to |
486 | erase screen} setting in the Terminal panel. Note that if you do |
487 | this in mid-session, it won't take effect until you reset the |
488 | terminal (see \k{faq-resetterm}). |
489 | |
70706890 |
490 | \S{faq-resetterm}{question} When I change some terminal settings, |
491 | nothing happens. |
f1453e5c |
492 | |
493 | Some of the terminal options (notably Auto Wrap and |
494 | background-colour screen erase) actually represent the \e{default} |
495 | setting, rather than the currently active setting. The server can |
496 | send sequences that modify these options in mid-session, but when |
497 | the terminal is reset (by server action, or by you choosing \q{Reset |
498 | Terminal} from the System menu) the defaults are restored. |
499 | |
500 | If you want to change one of these options in the middle of a |
501 | session, you will find that the change does not immediately take |
502 | effect. It will only take effect once you reset the terminal. |
503 | |
70706890 |
504 | \S{faq-altgr}{question} I can't type characters that require the |
505 | AltGr key. |
ee46ef84 |
506 | |
507 | In PuTTY version 0.51, the AltGr key was broken. The bug has been |
508 | fixed since then. |
509 | |
70706890 |
510 | \S{faq-idleout}{question} My PuTTY sessions unexpectedly close after |
511 | they are idle for a while. |
ee46ef84 |
512 | |
513 | Some types of firewall, and almost any router doing Network Address |
514 | Translation (NAT, also known as IP masquerading), will forget about |
515 | a connection through them if the connection does nothing for too |
516 | long. This will cause the connection to be rudely cut off when |
517 | contact is resumed. |
518 | |
519 | You can try to combat this by telling PuTTY to send \e{keepalives}: |
520 | packets of data which have no effect on the actual session, but |
521 | which reassure the router or firewall that the network connection is |
522 | still active and worth remembering about. |
523 | |
524 | Keepalives don't solve everything, unfortunately; although they |
525 | cause greater robustness against this sort of router, they can also |
526 | cause a \e{loss} of robustness against network dropouts. See |
527 | \k{config-keepalive} in the documentation for more discussion of |
528 | this. |
529 | |
70706890 |
530 | \S{faq-timeout}{question} PuTTY's network connections time out too |
531 | quickly when network connectivity is temporarily lost. |
ee46ef84 |
532 | |
533 | This is a Windows problem, not a PuTTY problem. The timeout value |
534 | can't be set on per application or per session basis. To increase |
535 | the TCP timeout globally, you need to tinker with the Registry. |
536 | |
537 | On Windows 95, 98 or ME, the registry key you need to change is |
538 | |
539 | \c HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\ |
540 | \c MSTCP\MaxDataRetries |
541 | |
542 | (it must be of type DWORD in Win95, or String in Win98/ME). |
543 | |
544 | On Windows NT or 2000, the registry key is |
545 | |
546 | \c HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ |
547 | \c Parameters\TcpMaxDataRetransmissions |
548 | |
549 | and it must be of type DWORD. |
550 | |
551 | Set the key's value to something like 10. This will cause Windows to |
552 | try harder to keep connections alive instead of abandoning them. |
553 | |
70706890 |
554 | \S{faq-puttyputty}{question} When I \cw{cat} a binary file, I get |
ee46ef84 |
555 | `PuTTYPuTTYPuTTY' on my command line. |
556 | |
557 | Don't \cw{cat} binary files, then. |
558 | |
559 | This is designed behaviour; when PuTTY receives the character |
560 | Control-E from the remote server, it interprets it as a request to |
561 | identify itself, and so it sends back the string \q{\cw{PuTTY}} as |
562 | if that string had been entered at the keyboard. Control-E should |
563 | only be sent by programs that are prepared to deal with the |
564 | response. Writing a binary file to your terminal is likely to output |
565 | many Control-E characters, and cause this behaviour. Don't do it. |
566 | It's a bad plan. |
567 | |
70706890 |
568 | \S{faq-puttyputty}{question} When I \cw{cat} a binary file, my |
569 | window title changes to a nonsense string. |
ee46ef84 |
570 | |
571 | Don't \cw{cat} binary files, then. |
572 | |
573 | It is designed behaviour that PuTTY should have the ability to |
574 | adjust the window title on instructions from the server. Normally |
575 | the control sequence that does this should only be sent |
576 | deliberately, by programs that know what they are doing and intend |
577 | to put meaningful text in the window title. Writing a binary file to |
578 | your terminal runs the risk of sending the same control sequence by |
579 | accident, and cause unexpected changes in the window title. Don't do |
580 | it. |
581 | |
70706890 |
582 | \S{faq-password}{question} My keyboard stops working once PuTTY |
583 | displays the password prompt. |
59c1f1f6 |
584 | |
585 | No, it doesn't. PuTTY just doesn't display the password you type, so |
586 | that someone looking at your screen can't see what it is. |
587 | |
588 | Unlike the Windows login prompts, PuTTY doesn't display the password |
589 | as a row of asterisks either. This is so that someone looking at |
590 | your screen can't even tell how \e{long} your password is, which |
591 | might be valuable information. |
592 | |
ee46ef84 |
593 | \H{faq-secure} Security questions |
594 | |
70706890 |
595 | \S{faq-publicpc}{question} Is it safe for me to download PuTTY and |
596 | use it on a public PC? |
ee46ef84 |
597 | |
598 | It depends on whether you trust that PC. If you don't trust the |
599 | public PC, don't use PuTTY on it, and don't use any other software |
600 | you plan to type passwords into either. It might be watching your |
601 | keystrokes, or it might tamper with the PuTTY binary you download. |
602 | There is \e{no} program safe enough that you can run it on an |
603 | actively malicious PC and get away with typing passwords into it. |
604 | |
605 | If you do trust the PC, then it's probably OK to use PuTTY on it |
606 | (but if you don't trust the network, then the PuTTY download might |
607 | be tampered with, so it would be better to carry PuTTY with you on a |
608 | floppy). |
609 | |
70706890 |
610 | \S{faq-cleanup}{question} What does PuTTY leave on a system? How can |
611 | I clean up after it? |
ee46ef84 |
612 | |
613 | PuTTY will leave some Registry entries, and a random seed file, on |
614 | the PC (see \k{faq-settings}). If you are using PuTTY on a public |
615 | PC, or somebody else's PC, you might want to clean these up when you |
616 | leave. You can do that automatically, by running the command |
617 | \c{putty -cleanup}. |
618 | |
70706890 |
619 | \S{faq-dsa}{question} How come PuTTY now supports DSA, when the |
620 | website used to say how insecure it was? |
ee46ef84 |
621 | |
622 | DSA has a major weakness \e{if badly implemented}: it relies on a |
623 | random number generator to far too great an extent. If the random |
624 | number generator produces a number an attacker can predict, the DSA |
625 | private key is exposed - meaning that the attacker can log in as you |
626 | on all systems that accept that key. |
627 | |
628 | The PuTTY policy changed because the developers were informed of |
629 | ways to implement DSA which do not suffer nearly as badly from this |
630 | weakness, and indeed which don't need to rely on random numbers at |
631 | all. For this reason we now believe PuTTY's DSA implementation is |
632 | probably OK. However, if you have the choice, we still recommend you |
633 | use RSA instead. |
634 | |
635 | \H{faq-admin} Administrative questions |
636 | |
70706890 |
637 | \S{faq-domain}{question} Would you like me to register you a nicer |
638 | domain name? |
ee46ef84 |
639 | |
640 | No, thank you. Even if you can find one (most of them seem to have |
641 | been registered already, by people who didn't ask whether we |
642 | actually wanted it before they applied), we're happy with the PuTTY |
643 | web site being exactly where it is. It's not hard to find (just type |
644 | \q{putty} into \W{http://www.google.com/}{google.com} and we're the |
645 | first link returned), and we don't believe the administrative hassle |
646 | of moving the site would be worth the benefit. |
647 | |
648 | In addition, if we \e{did} want a custom domain name, we would want |
649 | to run it ourselves, so we knew for certain that it would continue |
650 | to point where we wanted it, and wouldn't suddenly change or do |
651 | strange things. Having it registered for us by a third party who we |
652 | don't even know is not the best way to achieve this. |
653 | |
70706890 |
654 | \S{faq-webhosting}{question} Would you like free web hosting for the |
655 | PuTTY web site? |
ee46ef84 |
656 | |
657 | We already have some, thanks. |
658 | |
70706890 |
659 | \S{faq-sourceforge}{question} Why don't you move PuTTY to |
660 | SourceForge? |
ee46ef84 |
661 | |
662 | Partly, because we don't want to move the web site location (see |
663 | \k{faq-domain}). |
664 | |
665 | Also, security reasons. PuTTY is a security product, and as such it |
666 | is particularly important to guard the code and the web site against |
667 | unauthorised modifications which might introduce subtle security |
668 | flaws. Therefore, we prefer that the CVS repository, web site and |
669 | FTP site remain where they are, under the direct control of system |
670 | administrators we know and trust personally, rather than being run |
671 | by a large organisation full of people we've never met and which is |
672 | known to have had breakins in the past. |
673 | |
674 | No offence to SourceForge; I think they do a wonderful job. But |
675 | they're not ideal for everyone, and in particular they're not ideal |
676 | for us. |
677 | |
70706890 |
678 | \S{faq-mailinglist1}{question} Why can't I subscribe to the |
679 | putty-bugs mailing list? |
ee46ef84 |
680 | |
681 | Because you're not a member of the PuTTY core development team. The |
682 | putty-bugs mailing list is not a general newsgroup-like discussion |
683 | forum; it's a contact address for the core developers, and an |
684 | \e{internal} mailing list for us to discuss things among ourselves. |
685 | If we opened it up for everybody to subscribe to, it would turn into |
686 | something more like a newsgroup and we would be completely |
687 | overwhelmed by the volume of traffic. It's hard enough to keep up |
688 | with the list as it is. |
689 | |
70706890 |
690 | \S{faq-mailinglist2}{question} If putty-bugs isn't a |
691 | general-subscription mailing list, what is? |
ee46ef84 |
692 | |
693 | There isn't one, that we know of. |
694 | |
695 | If someone else wants to set up a mailing list for PuTTY users to |
696 | help each other with common problems, that would be fine with us; |
697 | but the PuTTY team would almost certainly not have the time to read |
698 | it, so any questions the list couldn't answer would have to be |
699 | forwarded on to us by the questioner. In any case, it's probably |
700 | better to use the established newsgroup \cw{comp.security.ssh} for |
701 | this purpose. |
702 | |
70706890 |
703 | \S{faq-donations}{question} How can I donate to PuTTY development? |
ee46ef84 |
704 | |
705 | Please, \e{please} don't feel you have to. PuTTY is completely free |
706 | software, and not shareware. We think it's very important that |
707 | \e{everybody} who wants to use PuTTY should be able to, whether they |
708 | have any money or not; so the last thing we would want is for a |
709 | PuTTY user to feel guilty because they haven't paid us any money. If |
710 | you want to keep your money, please do keep it. We wouldn't dream of |
711 | asking for any. |
712 | |
713 | Having said all that, if you still really \e{want} to give us money, |
714 | we won't argue :-) The easiest way for us to accept donations is if |
715 | you go to \W{http://www.e-gold.com}\cw{www.e-gold.com}, and deposit |
716 | your donation in account number 174769. Then send us e-mail to let |
717 | us know you've done so (otherwise we might not notice for months!). |
718 | |
719 | Small donations (tens of dollars or tens of euros) will probably be |
720 | spent on beer or curry, which helps motivate our volunteer team to |
721 | continue doing this for the world. Larger donations will be spent on |
722 | something that actually helps development, if we can find anything |
723 | (perhaps new hardware, or a copy of Windows 2000), but if we can't |
724 | find anything then we'll just distribute the money among the |
725 | developers. If you want to be sure your donation is going towards |
726 | something worthwhile, ask us first. If you don't like these terms, |
727 | feel perfectly free not to donate. We don't mind. |
728 | |
70706890 |
729 | \S{faq-pronounce}{question} How do I pronounce PuTTY? |
ee46ef84 |
730 | |
731 | Exactly like the normal word \q{putty}. Just like the stuff you put |
732 | on window frames. (One of the reasons it's called PuTTY is because |
733 | it makes Windows usable. :-) |