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