| 1 | \define{versionidfaq} \versionid $Id$ |
| 2 | |
| 3 | \A{faq} PuTTY \i{FAQ} |
| 4 | |
| 5 | This FAQ is published on the PuTTY web site, and also provided as an |
| 6 | appendix in the manual. |
| 7 | |
| 8 | \H{faq-intro} Introduction |
| 9 | |
| 10 | \S{faq-what}{Question} What is PuTTY? |
| 11 | |
| 12 | PuTTY is a client program for the SSH, Telnet and Rlogin network |
| 13 | protocols. |
| 14 | |
| 15 | These protocols are all used to run a remote session on a computer, |
| 16 | over a network. PuTTY implements the client end of that session: the |
| 17 | end at which the session is displayed, rather than the end at which |
| 18 | it runs. |
| 19 | |
| 20 | In really simple terms: you run PuTTY on a Windows machine, and tell |
| 21 | it to connect to (for example) a Unix machine. PuTTY opens a window. |
| 22 | Then, anything you type into that window is sent straight to the |
| 23 | Unix machine, and everything the Unix machine sends back is |
| 24 | displayed in the window. So you can work on the Unix machine as if |
| 25 | you were sitting at its console, while actually sitting somewhere |
| 26 | else. |
| 27 | |
| 28 | \H{faq-support} Features supported in PuTTY |
| 29 | |
| 30 | \I{supported features}In general, if you want to know if PuTTY supports |
| 31 | a particular feature, you should look for it on the |
| 32 | \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/}{PuTTY web site}. |
| 33 | In particular: |
| 34 | |
| 35 | \b try the |
| 36 | \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html}{changes |
| 37 | page}, and see if you can find the feature on there. If a feature is |
| 38 | listed there, it's been implemented. If it's listed as a change made |
| 39 | \e{since} the latest version, it should be available in the |
| 40 | development snapshots, in which case testing will be very welcome. |
| 41 | |
| 42 | \b try the |
| 43 | \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/}{Wishlist |
| 44 | page}, and see if you can find the feature there. If it's on there, |
| 45 | and not in the \q{Recently fixed} section, it probably \e{hasn't} been |
| 46 | implemented. |
| 47 | |
| 48 | \S{faq-ssh2}{Question} Does PuTTY support SSH-2? |
| 49 | |
| 50 | Yes. SSH-2 support has been available in PuTTY since version 0.50. |
| 51 | |
| 52 | Public key authentication (both RSA and DSA) in SSH-2 is new in |
| 53 | version 0.52. |
| 54 | |
| 55 | \S{faq-ssh2-keyfmt}{Question} Does PuTTY support reading OpenSSH or |
| 56 | \cw{ssh.com} SSH-2 private key files? |
| 57 | |
| 58 | PuTTY doesn't support this natively, but as of 0.53 |
| 59 | PuTTYgen can convert both OpenSSH and \cw{ssh.com} private key |
| 60 | files into PuTTY's format. |
| 61 | |
| 62 | \S{faq-ssh1}{Question} Does PuTTY support SSH-1? |
| 63 | |
| 64 | Yes. SSH-1 support has always been available in PuTTY. |
| 65 | |
| 66 | \S{faq-localecho}{Question} Does PuTTY support \i{local echo}? |
| 67 | |
| 68 | Yes. Version 0.52 has proper support for local echo. |
| 69 | |
| 70 | In version 0.51 and before, local echo could not be separated from |
| 71 | local line editing (where you type a line of text locally, and it is |
| 72 | not sent to the server until you press Return, so you have the |
| 73 | chance to edit it and correct mistakes \e{before} the server sees |
| 74 | it). New in version 0.52, local echo and local line editing are |
| 75 | separate options, and by default PuTTY will try to determine |
| 76 | automatically whether to enable them or not, based on which protocol |
| 77 | you have selected and also based on hints from the server. If you |
| 78 | have a problem with PuTTY's default choice, you can force each |
| 79 | option to be enabled or disabled as you choose. The controls are in |
| 80 | the Terminal panel, in the section marked \q{Line discipline |
| 81 | options}. |
| 82 | |
| 83 | \S{faq-savedsettings}{Question} Does PuTTY support storing settings, |
| 84 | so I don't have to change them every time? |
| 85 | |
| 86 | Yes, all of PuTTY's settings can be saved in named session profiles. |
| 87 | You can also change the default settings that are used for new sessions. |
| 88 | See \k{config-saving} in the documentation for how to do this. |
| 89 | |
| 90 | \S{faq-disksettings}{Question} Does PuTTY support storing its |
| 91 | settings in a disk file? |
| 92 | |
| 93 | Not at present, although \k{config-file} in the documentation gives |
| 94 | a method of achieving the same effect. |
| 95 | |
| 96 | \S{faq-fullscreen}{Question} Does PuTTY support full-screen mode, |
| 97 | like a DOS box? |
| 98 | |
| 99 | Yes; this is a new feature in version 0.52. |
| 100 | |
| 101 | \S{faq-password-remember}{Question} Does PuTTY have the ability to |
| 102 | \i{remember my password} so I don't have to type it every time? |
| 103 | |
| 104 | No, it doesn't. |
| 105 | |
| 106 | Remembering your password is a bad plan for obvious security |
| 107 | reasons: anyone who gains access to your machine while you're away |
| 108 | from your desk can find out the remembered password, and use it, |
| 109 | abuse it or change it. |
| 110 | |
| 111 | In addition, it's not even \e{possible} for PuTTY to automatically |
| 112 | send your password in a Telnet session, because Telnet doesn't give |
| 113 | the client software any indication of which part of the login |
| 114 | process is the password prompt. PuTTY would have to guess, by |
| 115 | looking for words like \q{password} in the session data; and if your |
| 116 | login program is written in something other than English, this won't |
| 117 | work. |
| 118 | |
| 119 | In SSH, remembering your password would be possible in theory, but |
| 120 | there doesn't seem to be much point since SSH supports public key |
| 121 | authentication, which is more flexible and more secure. See |
| 122 | \k{pubkey} in the documentation for a full discussion of public key |
| 123 | authentication. |
| 124 | |
| 125 | \S{faq-hostkeys}{Question} Is there an option to turn off the |
| 126 | \I{verifying the host key}annoying host key prompts? |
| 127 | |
| 128 | No, there isn't. And there won't be. Even if you write it yourself |
| 129 | and send us the patch, we won't accept it. |
| 130 | |
| 131 | Those annoying host key prompts are the \e{whole point} of SSH. |
| 132 | Without them, all the cryptographic technology SSH uses to secure |
| 133 | your session is doing nothing more than making an attacker's job |
| 134 | slightly harder; instead of sitting between you and the server with |
| 135 | a packet sniffer, the attacker must actually subvert a router and |
| 136 | start modifying the packets going back and forth. But that's not all |
| 137 | that much harder than just sniffing; and without host key checking, |
| 138 | it will go completely undetected by client or server. |
| 139 | |
| 140 | Host key checking is your guarantee that the encryption you put on |
| 141 | your data at the client end is the \e{same} encryption taken off the |
| 142 | data at the server end; it's your guarantee that it hasn't been |
| 143 | removed and replaced somewhere on the way. Host key checking makes |
| 144 | the attacker's job \e{astronomically} hard, compared to packet |
| 145 | sniffing, and even compared to subverting a router. Instead of |
| 146 | applying a little intelligence and keeping an eye on Bugtraq, the |
| 147 | attacker must now perform a brute-force attack against at least one |
| 148 | military-strength cipher. That insignificant host key prompt really |
| 149 | does make \e{that} much difference. |
| 150 | |
| 151 | If you're having a specific problem with host key checking - perhaps |
| 152 | you want an automated batch job to make use of PSCP or Plink, and |
| 153 | the interactive host key prompt is hanging the batch process - then |
| 154 | the right way to fix it is to add the correct host key to the |
| 155 | Registry in advance. That way, you retain the \e{important} feature |
| 156 | of host key checking: the right key will be accepted and the wrong |
| 157 | ones will not. Adding an option to turn host key checking off |
| 158 | completely is the wrong solution and we will not do it. |
| 159 | |
| 160 | If you have host keys available in the common \i\c{known_hosts} format, |
| 161 | we have a script called |
| 162 | \W{http://www.tartarus.org/~simon-anonsvn/viewcvs.cgi/putty/contrib/kh2reg.py?view=markup}\c{kh2reg.py} |
| 163 | to convert them to a Windows .REG file, which can be installed ahead of |
| 164 | time by double-clicking or using \c{REGEDIT}. |
| 165 | |
| 166 | \S{faq-server}{Question} Will you write an SSH server for the PuTTY |
| 167 | suite, to go with the client? |
| 168 | |
| 169 | No. The only reason we might want to would be if we could easily |
| 170 | re-use existing code and significantly cut down the effort. We don't |
| 171 | believe this is the case; there just isn't enough common ground |
| 172 | between an SSH client and server to make it worthwhile. |
| 173 | |
| 174 | If someone else wants to use bits of PuTTY in the process of writing |
| 175 | a Windows SSH server, they'd be perfectly welcome to of course, but |
| 176 | I really can't see it being a lot less effort for us to do that than |
| 177 | it would be for us to write a server from the ground up. We don't |
| 178 | have time, and we don't have motivation. The code is available if |
| 179 | anyone else wants to try it. |
| 180 | |
| 181 | \S{faq-pscp-ascii}{Question} Can PSCP or PSFTP transfer files in |
| 182 | \i{ASCII} mode? |
| 183 | |
| 184 | Unfortunately not. |
| 185 | |
| 186 | Until recently, this was a limitation of the file transfer protocols: |
| 187 | the SCP and SFTP protocols had no notion of transferring a file in |
| 188 | anything other than binary mode. (This is still true of SCP.) |
| 189 | |
| 190 | The current draft protocol spec of SFTP proposes a means of |
| 191 | implementing ASCII transfer. At some point PSCP/PSFTP may implement |
| 192 | this proposal. |
| 193 | |
| 194 | \H{faq-ports} Ports to other operating systems |
| 195 | |
| 196 | The eventual goal is for PuTTY to be a multi-platform program, able |
| 197 | to run on at least Windows, Mac OS and Unix. |
| 198 | |
| 199 | Porting will become easier once PuTTY has a generalised porting |
| 200 | layer, drawing a clear line between platform-dependent and |
| 201 | platform-independent code. The general intention was for this |
| 202 | porting layer to evolve naturally as part of the process of doing |
| 203 | the first port; a Unix port has now been released and the plan |
| 204 | seems to be working so far. |
| 205 | |
| 206 | \S{faq-ports-general}{Question} What ports of PuTTY exist? |
| 207 | |
| 208 | Currently, release versions of PuTTY tools only run on full Win32 |
| 209 | systems and Unix. \q{Win32} includes Windows 95, 98, and ME, and it |
| 210 | includes Windows NT, Windows 2000 and Windows XP. |
| 211 | |
| 212 | In the development code, a partial port to the Mac OS (see |
| 213 | \k{faq-mac-port}) is under way. |
| 214 | |
| 215 | Currently PuTTY does \e{not} run on Windows CE (see \k{faq-wince}), |
| 216 | and it does not quite run on the Win32s environment under Windows |
| 217 | 3.1 (see \k{faq-win31}). |
| 218 | |
| 219 | We do not have release-quality ports for any other systems at the |
| 220 | present time. If anyone told you we had an EPOC port, or an iPaq port, |
| 221 | or any other port of PuTTY, they were mistaken. We don't. |
| 222 | |
| 223 | There are some third-party ports to various platforms, mentioned |
| 224 | on the Links page of our website. |
| 225 | |
| 226 | \S{faq-unix}{Question} \I{Unix version}Is there a port to Unix? |
| 227 | |
| 228 | As of 0.54, there are Unix ports of most of the traditional PuTTY |
| 229 | tools, and also one entirely new application. |
| 230 | |
| 231 | If you look at the source release, you should find a \c{unix} |
| 232 | subdirectory containing \c{Makefile.gtk}, which should build you Unix |
| 233 | ports of Plink, PuTTY itself, PuTTYgen, PSCP, PSFTP, and also |
| 234 | \i\c{pterm} - an \cw{xterm}-type program which supports the same |
| 235 | terminal emulation as PuTTY. We do not yet have a Unix port of |
| 236 | Pageant. |
| 237 | |
| 238 | If you don't have \i{Gtk}, you should still be able to build the |
| 239 | command-line tools. |
| 240 | |
| 241 | Note that Unix PuTTY has mostly only been tested on Linux so far; |
| 242 | portability problems such as BSD-style ptys or different header file |
| 243 | requirements are expected. |
| 244 | |
| 245 | \S{faq-unix-why}{Question} What's the point of the Unix port? Unix |
| 246 | has OpenSSH. |
| 247 | |
| 248 | All sorts of little things. \c{pterm} is directly useful to anyone |
| 249 | who prefers PuTTY's terminal emulation to \c{xterm}'s, which at |
| 250 | least some people do. Unix Plink has apparently found a niche among |
| 251 | people who find the complexity of OpenSSL makes OpenSSH hard to |
| 252 | install (and who don't mind Plink not having as many features). Some |
| 253 | users want to generate a large number of SSH keys on Unix and then |
| 254 | copy them all into PuTTY, and the Unix PuTTYgen should allow them to |
| 255 | automate that conversion process. |
| 256 | |
| 257 | There were development advantages as well; porting PuTTY to Unix was |
| 258 | a valuable path-finding effort for other future ports, and also |
| 259 | allowed us to use the excellent Linux tool |
| 260 | \W{http://valgrind.kde.org/}{Valgrind} to help with debugging, which |
| 261 | has already improved PuTTY's stability on \e{all} platforms. |
| 262 | |
| 263 | However, if you're a Unix user and you can see no reason to switch |
| 264 | from OpenSSH to PuTTY/Plink, then you're probably right. We don't |
| 265 | expect our Unix port to be the right thing for everybody. |
| 266 | |
| 267 | \S{faq-wince}{Question} Will there be a port to Windows CE or PocketPC? |
| 268 | |
| 269 | It's currently being worked on, but it's only in its early stages yet, |
| 270 | and certainly isn't yet useful. PuTTY on portable devices would |
| 271 | clearly be a useful thing, so in the long term I hope it can be |
| 272 | brought up to release quality. |
| 273 | |
| 274 | There's also a third-party port at |
| 275 | \W{http://pocketputty.duxy.net/}\c{http://pocketputty.duxy.net/}. |
| 276 | |
| 277 | \S{faq-win31}{Question} Is there a port to \i{Windows 3.1}? |
| 278 | |
| 279 | PuTTY is a 32-bit application from the ground up, so it won't run on |
| 280 | Windows 3.1 as a native 16-bit program; and it would be \e{very} |
| 281 | hard to port it to do so, because of Windows 3.1's vile memory |
| 282 | allocation mechanisms. |
| 283 | |
| 284 | However, it is possible in theory to compile the existing PuTTY |
| 285 | source in such a way that it will run under \i{Win32s} (an extension to |
| 286 | Windows 3.1 to let you run 32-bit programs). In order to do this |
| 287 | you'll need the right kind of C compiler - modern versions of Visual |
| 288 | C at least have stopped being backwards compatible to Win32s. Also, |
| 289 | the last time we tried this it didn't work very well. |
| 290 | |
| 291 | If you're interested in running PuTTY under Windows 3.1, help and |
| 292 | testing in this area would be very welcome! |
| 293 | |
| 294 | \S{faq-mac-port}{Question} Will there be a port to the \I{Mac OS}Mac? |
| 295 | |
| 296 | There are several answers to this question: |
| 297 | |
| 298 | \b The Unix/Gtk port is already fully working under Mac OS X as an X11 |
| 299 | application. |
| 300 | |
| 301 | \b A native (Cocoa) Mac OS X port is in progress. It's just about |
| 302 | usable, but is of nowhere near release quality yet, and is likely to |
| 303 | behave in unexpected ways. |
| 304 | |
| 305 | \b A separate port to the classic Mac OS (pre-OSX) is also in |
| 306 | progress; it too is not ready yet. |
| 307 | |
| 308 | \S{faq-epoc}{Question} Will there be a port to EPOC? |
| 309 | |
| 310 | I hope so, but given that ports aren't really progressing very fast |
| 311 | even on systems the developers \e{do} already know how to program |
| 312 | for, it might be a long time before any of us get round to learning |
| 313 | a new system and doing the port for that. |
| 314 | |
| 315 | However, some of the work has been done by other people, and a beta |
| 316 | port of PuTTY for the Nokia 9200 Communicator series is available |
| 317 | from \W{http://s2putty.sourceforge.net/}\cw{http://s2putty.sourceforge.net/} |
| 318 | |
| 319 | \H{faq-embedding} Embedding PuTTY in other programs |
| 320 | |
| 321 | \S{faq-dll}{Question} Is the SSH or Telnet code available as a DLL? |
| 322 | |
| 323 | No, it isn't. It would take a reasonable amount of rewriting for |
| 324 | this to be possible, and since the PuTTY project itself doesn't |
| 325 | believe in DLLs (they make installation more error-prone) none of us |
| 326 | has taken the time to do it. |
| 327 | |
| 328 | Most of the code cleanup work would be a good thing to happen in |
| 329 | general, so if anyone feels like helping, we wouldn't say no. |
| 330 | |
| 331 | \S{faq-vb}{Question} Is the SSH or Telnet code available as a Visual |
| 332 | Basic component? |
| 333 | |
| 334 | No, it isn't. None of the PuTTY team uses Visual Basic, and none of |
| 335 | us has any particular need to make SSH connections from a Visual |
| 336 | Basic application. In addition, all the preliminary work to turn it |
| 337 | into a DLL would be necessary first; and furthermore, we don't even |
| 338 | know how to write VB components. |
| 339 | |
| 340 | If someone offers to do some of this work for us, we might consider |
| 341 | it, but unless that happens I can't see VB integration being |
| 342 | anywhere other than the very bottom of our priority list. |
| 343 | |
| 344 | \S{faq-ipc}{Question} How can I use PuTTY to make an SSH connection |
| 345 | from within another program? |
| 346 | |
| 347 | Probably your best bet is to use Plink, the command-line connection |
| 348 | tool. If you can start Plink as a second Windows process, and |
| 349 | arrange for your primary process to be able to send data to the |
| 350 | Plink process, and receive data from it, through pipes, then you |
| 351 | should be able to make SSH connections from your program. |
| 352 | |
| 353 | This is what CVS for Windows does, for example. |
| 354 | |
| 355 | \H{faq-details} Details of PuTTY's operation |
| 356 | |
| 357 | \S{faq-term}{Question} What \i{terminal type} does PuTTY use? |
| 358 | |
| 359 | For most purposes, PuTTY can be considered to be an \cw{xterm} |
| 360 | terminal. |
| 361 | |
| 362 | PuTTY also supports some terminal \i{control sequences} not supported by |
| 363 | the real \cw{xterm}: notably the Linux console sequences that |
| 364 | reconfigure the colour palette, and the title bar control sequences |
| 365 | used by \i\cw{DECterm} (which are different from the \cw{xterm} ones; |
| 366 | PuTTY supports both). |
| 367 | |
| 368 | By default, PuTTY announces its terminal type to the server as |
| 369 | \c{xterm}. If you have a problem with this, you can reconfigure it |
| 370 | to say something else; \c{vt220} might help if you have trouble. |
| 371 | |
| 372 | \S{faq-settings}{Question} Where does PuTTY store its data? |
| 373 | |
| 374 | On Windows, PuTTY stores most of its data (saved sessions, SSH host |
| 375 | keys) in the \i{Registry}. The precise location is |
| 376 | |
| 377 | \c HKEY_CURRENT_USER\Software\SimonTatham\PuTTY |
| 378 | |
| 379 | and within that area, saved sessions are stored under \c{Sessions} |
| 380 | while host keys are stored under \c{SshHostKeys}. |
| 381 | |
| 382 | PuTTY also requires a random number seed file, to improve the |
| 383 | unpredictability of randomly chosen data needed as part of the SSH |
| 384 | cryptography. This is stored by default in a file called \i\c{PUTTY.RND} |
| 385 | in your Windows home directory (\c{%HOMEDRIVE%\\%HOMEPATH%}), or in |
| 386 | the actual Windows directory (such as \c{C:\\WINDOWS}) if the home |
| 387 | directory doesn't exist, for example if you're using Win95. If you |
| 388 | want to change the location of the random number seed file, you can |
| 389 | put your chosen pathname in the Registry, at |
| 390 | |
| 391 | \c HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\RandSeedFile |
| 392 | |
| 393 | On Unix, PuTTY stores all of this data in a directory \cw{~/.putty}. |
| 394 | |
| 395 | \H{faq-howto} HOWTO questions |
| 396 | |
| 397 | \S{faq-commands}{Question} \I{commands on the server}What commands |
| 398 | can I type into my PuTTY terminal window? |
| 399 | |
| 400 | This is not a question you should be asking \e{us}. You need to read |
| 401 | the manuals, or ask the administrator, of \e{the computer you have |
| 402 | connected to}. |
| 403 | |
| 404 | PuTTY does not process the commands you type into it. It's only a |
| 405 | communications tool. It makes a connection to another computer; it |
| 406 | passes the commands you type to that other computer; and it passes |
| 407 | the other computer's responses back to you. Therefore, the precise |
| 408 | range of commands you can use will not depend on PuTTY, but on what |
| 409 | kind of computer you have connected to and what software is running |
| 410 | on it. The PuTTY team cannot help you with that. |
| 411 | |
| 412 | (Think of PuTTY as being a bit like a telephone. If you phone |
| 413 | somebody up and you don't know what language to speak to make them |
| 414 | understand you, it isn't \e{the telephone company}'s job to find |
| 415 | that out for you. We just provide the means for you to get in touch; |
| 416 | making yourself understood is somebody else's problem.) |
| 417 | |
| 418 | If you are unsure of where to start looking for the administrator of |
| 419 | your server, a good place to start might be to remember how you |
| 420 | found out the host name in the PuTTY configuration. If you were |
| 421 | given that host name by e-mail, for example, you could try asking |
| 422 | the person who sent you that e-mail. If your company's IT department |
| 423 | provided you with ready-made PuTTY saved sessions, then that IT |
| 424 | department can probably also tell you something about what commands |
| 425 | you can type during those sessions. But the PuTTY maintainer team |
| 426 | does not administer any server you are likely to be connecting to, |
| 427 | and cannot help you with questions of this type. |
| 428 | |
| 429 | \S{faq-startmax}{Question} How can I make PuTTY start up \i{maximise}d? |
| 430 | |
| 431 | Create a Windows shortcut to start PuTTY from, and set it as \q{Run |
| 432 | Maximized}. |
| 433 | |
| 434 | \S{faq-startsess}{Question} How can I create a \i{Windows shortcut} to |
| 435 | start a particular saved session directly? |
| 436 | |
| 437 | To run a PuTTY session saved under the name \q{\cw{mysession}}, |
| 438 | create a Windows shortcut that invokes PuTTY with a command line |
| 439 | like |
| 440 | |
| 441 | \c \path\name\to\putty.exe -load "mysession" |
| 442 | |
| 443 | (Note: prior to 0.53, the syntax was \c{@session}. This is now |
| 444 | deprecated and may be removed at some point.) |
| 445 | |
| 446 | \S{faq-startssh}{Question} How can I start an SSH session straight |
| 447 | from the command line? |
| 448 | |
| 449 | Use the command line \c{putty -ssh host.name}. Alternatively, create |
| 450 | a saved session that specifies the SSH protocol, and start the saved |
| 451 | session as shown in \k{faq-startsess}. |
| 452 | |
| 453 | \S{faq-cutpaste}{Question} How do I \i{copy and paste} between PuTTY and |
| 454 | other Windows applications? |
| 455 | |
| 456 | Copy and paste works similarly to the X Window System. You use the |
| 457 | left mouse button to select text in the PuTTY window. The act of |
| 458 | selection \e{automatically} copies the text to the clipboard: there |
| 459 | is no need to press Ctrl-Ins or Ctrl-C or anything else. In fact, |
| 460 | pressing Ctrl-C will send a Ctrl-C character to the other end of |
| 461 | your connection (just like it does the rest of the time), which may |
| 462 | have unpleasant effects. The \e{only} thing you need to do, to copy |
| 463 | text to the clipboard, is to select it. |
| 464 | |
| 465 | To paste the clipboard contents into a PuTTY window, by default you |
| 466 | click the right mouse button. If you have a three-button mouse and |
| 467 | are used to X applications, you can configure pasting to be done by |
| 468 | the middle button instead, but this is not the default because most |
| 469 | Windows users don't have a middle button at all. |
| 470 | |
| 471 | You can also paste by pressing Shift-Ins. |
| 472 | |
| 473 | \S{faq-options}{Question} How do I use all PuTTY's features (public |
| 474 | keys, proxying, cipher selection, etc.) in PSCP, PSFTP and Plink? |
| 475 | |
| 476 | Most major features (e.g., public keys, port forwarding) are available |
| 477 | through command line options. See the documentation. |
| 478 | |
| 479 | Not all features are accessible from the command line yet, although |
| 480 | we'd like to fix this. In the meantime, you can use most of |
| 481 | PuTTY's features if you create a PuTTY saved session, and then use |
| 482 | the name of the saved session on the command line in place of a |
| 483 | hostname. This works for PSCP, PSFTP and Plink (but don't expect |
| 484 | port forwarding in the file transfer applications!). |
| 485 | |
| 486 | \S{faq-pscp}{Question} How do I use PSCP.EXE? When I double-click it |
| 487 | gives me a command prompt window which then closes instantly. |
| 488 | |
| 489 | PSCP is a command-line application, not a GUI application. If you |
| 490 | run it without arguments, it will simply print a help message and |
| 491 | terminate. |
| 492 | |
| 493 | To use PSCP properly, run it from a Command Prompt window. See |
| 494 | \k{pscp} in the documentation for more details. |
| 495 | |
| 496 | \S{faq-pscp-spaces}{Question} \I{spaces in filenames}How do I use |
| 497 | PSCP to copy a file whose name has spaces in? |
| 498 | |
| 499 | If PSCP is using the traditional SCP protocol, this is confusing. If |
| 500 | you're specifying a file at the local end, you just use one set of |
| 501 | quotes as you would normally do: |
| 502 | |
| 503 | \c pscp "local filename with spaces" user@host: |
| 504 | \c pscp user@host:myfile "local filename with spaces" |
| 505 | |
| 506 | But if the filename you're specifying is on the \e{remote} side, you |
| 507 | have to use backslashes and two sets of quotes: |
| 508 | |
| 509 | \c pscp user@host:"\"remote filename with spaces\"" local_filename |
| 510 | \c pscp local_filename user@host:"\"remote filename with spaces\"" |
| 511 | |
| 512 | Worse still, in a remote-to-local copy you have to specify the local |
| 513 | file name explicitly, otherwise PSCP will complain that they don't |
| 514 | match (unless you specified the \c{-unsafe} option). The following |
| 515 | command will give an error message: |
| 516 | |
| 517 | \c c:\>pscp user@host:"\"oo er\"" . |
| 518 | \c warning: remote host tried to write to a file called 'oo er' |
| 519 | \c when we requested a file called '"oo er"'. |
| 520 | |
| 521 | Instead, you need to specify the local file name in full: |
| 522 | |
| 523 | \c c:\>pscp user@host:"\"oo er\"" "oo er" |
| 524 | |
| 525 | If PSCP is using the newer SFTP protocol, none of this is a problem, |
| 526 | and all filenames with spaces in are specified using a single pair |
| 527 | of quotes in the obvious way: |
| 528 | |
| 529 | \c pscp "local file" user@host: |
| 530 | \c pscp user@host:"remote file" . |
| 531 | |
| 532 | \H{faq-trouble} Troubleshooting |
| 533 | |
| 534 | \S{faq-incorrect-mac}{Question} Why do I see \q{Incorrect MAC |
| 535 | received on packet}? |
| 536 | |
| 537 | One possible cause of this that used to be common is a bug in old |
| 538 | SSH-2 servers distributed by \cw{ssh.com}. (This is not the only |
| 539 | possible cause; see \k{errors-crc} in the documentation.) |
| 540 | Version 2.3.0 and below of their SSH-2 server |
| 541 | constructs Message Authentication Codes in the wrong way, and |
| 542 | expects the client to construct them in the same wrong way. PuTTY |
| 543 | constructs the MACs correctly by default, and hence these old |
| 544 | servers will fail to work with it. |
| 545 | |
| 546 | If you are using PuTTY version 0.52 or better, this should work |
| 547 | automatically: PuTTY should detect the buggy servers from their |
| 548 | version number announcement, and automatically start to construct |
| 549 | its MACs in the same incorrect manner as they do, so it will be able |
| 550 | to work with them. |
| 551 | |
| 552 | If you are using PuTTY version 0.51 or below, you can enable the |
| 553 | workaround by going to the SSH panel and ticking the box labelled |
| 554 | \q{Imitate SSH2 MAC bug}. It's possible that you might have to do |
| 555 | this with 0.52 as well, if a buggy server exists that PuTTY doesn't |
| 556 | know about. |
| 557 | |
| 558 | In this context MAC stands for \ii{Message Authentication Code}. It's a |
| 559 | cryptographic term, and it has nothing at all to do with Ethernet |
| 560 | MAC (Media Access Control) addresses. |
| 561 | |
| 562 | \S{faq-pscp-protocol}{Question} Why do I see \q{Fatal: Protocol |
| 563 | error: Expected control record} in PSCP? |
| 564 | |
| 565 | This happens because PSCP was expecting to see data from the server |
| 566 | that was part of the PSCP protocol exchange, and instead it saw data |
| 567 | that it couldn't make any sense of at all. |
| 568 | |
| 569 | This almost always happens because the \i{startup scripts} in your |
| 570 | account on the server machine are generating output. This is |
| 571 | impossible for PSCP, or any other SCP client, to work around. You |
| 572 | should never use startup files (\c{.bashrc}, \c{.cshrc} and so on) |
| 573 | which generate output in non-interactive sessions. |
| 574 | |
| 575 | This is not actually a PuTTY problem. If PSCP fails in this way, |
| 576 | then all other SCP clients are likely to fail in exactly the same |
| 577 | way. The problem is at the server end. |
| 578 | |
| 579 | \S{faq-colours}{Question} I clicked on a colour in the \ii{Colours} |
| 580 | panel, and the colour didn't change in my terminal. |
| 581 | |
| 582 | That isn't how you're supposed to use the Colours panel. |
| 583 | |
| 584 | During the course of a session, PuTTY potentially uses \e{all} the |
| 585 | colours listed in the Colours panel. It's not a question of using |
| 586 | only one of them and you choosing which one; PuTTY will use them |
| 587 | \e{all}. The purpose of the Colours panel is to let you adjust the |
| 588 | appearance of all the colours. So to change the colour of the |
| 589 | cursor, for example, you would select \q{Cursor Colour}, press the |
| 590 | \q{Modify} button, and select a new colour from the dialog box that |
| 591 | appeared. Similarly, if you want your session to appear in green, |
| 592 | you should select \q{Default Foreground} and press \q{Modify}. |
| 593 | Clicking on \q{ANSI Green} won't turn your session green; it will |
| 594 | only allow you to adjust the \e{shade} of green used when PuTTY is |
| 595 | instructed by the server to display green text. |
| 596 | |
| 597 | \S{faq-winsock2}{Question} Plink on \i{Windows 95} says it can't find |
| 598 | \i\cw{WS2_32.DLL}. |
| 599 | |
| 600 | Plink requires the extended Windows network library, WinSock version |
| 601 | 2. This is installed as standard on Windows 98 and above, and on |
| 602 | Windows NT, and even on later versions of Windows 95; but early |
| 603 | Win95 installations don't have it. |
| 604 | |
| 605 | In order to use Plink on these systems, you will need to download |
| 606 | the |
| 607 | \W{http://www.microsoft.com/windows95/downloads/contents/wuadmintools/s_wunetworkingtools/w95sockets2/}{WinSock 2 upgrade}: |
| 608 | |
| 609 | \c http://www.microsoft.com/windows95/downloads/contents/ |
| 610 | \c wuadmintools/s_wunetworkingtools/w95sockets2/ |
| 611 | |
| 612 | \S{faq-outofmem}{Question} After trying to establish an SSH-2 |
| 613 | connection, PuTTY says \q{\ii{Out of memory}} and dies. |
| 614 | |
| 615 | If this happens just while the connection is starting up, this often |
| 616 | indicates that for some reason the client and server have failed to |
| 617 | establish a session encryption key. Somehow, they have performed |
| 618 | calculations that should have given each of them the same key, but |
| 619 | have ended up with different keys; so data encrypted by one and |
| 620 | decrypted by the other looks like random garbage. |
| 621 | |
| 622 | This causes an \q{out of memory} error because the first encrypted |
| 623 | data PuTTY expects to see is the length of an SSH message. Normally |
| 624 | this will be something well under 100 bytes. If the decryption has |
| 625 | failed, PuTTY will see a completely random length in the region of |
| 626 | two \e{gigabytes}, and will try to allocate enough memory to store |
| 627 | this non-existent message. This will immediately lead to it thinking |
| 628 | it doesn't have enough memory, and panicking. |
| 629 | |
| 630 | If this happens to you, it is quite likely to still be a PuTTY bug |
| 631 | and you should report it (although it might be a bug in your SSH |
| 632 | server instead); but it doesn't necessarily mean you've actually run |
| 633 | out of memory. |
| 634 | |
| 635 | \S{faq-outofmem2}{Question} When attempting a file transfer, either |
| 636 | PSCP or PSFTP says \q{\ii{Out of memory}} and dies. |
| 637 | |
| 638 | This is almost always caused by your \i{login scripts} on the server |
| 639 | generating output. PSCP or PSFTP will receive that output when they |
| 640 | were expecting to see the start of a file transfer protocol, and |
| 641 | they will attempt to interpret the output as file-transfer protocol. |
| 642 | This will usually lead to an \q{out of memory} error for much the |
| 643 | same reasons as given in \k{faq-outofmem}. |
| 644 | |
| 645 | This is a setup problem in your account on your server, \e{not} a |
| 646 | PSCP/PSFTP bug. Your login scripts should \e{never} generate output |
| 647 | during non-interactive sessions; secure file transfer is not the |
| 648 | only form of remote access that will break if they do. |
| 649 | |
| 650 | On Unix, a simple fix is to ensure that all the parts of your login |
| 651 | script that might generate output are in \c{.profile} (if you use a |
| 652 | Bourne shell derivative) or \c{.login} (if you use a C shell). |
| 653 | Putting them in more general files such as \c{.bashrc} or \c{.cshrc} |
| 654 | is liable to lead to problems. |
| 655 | |
| 656 | \S{faq-psftp-slow}{Question} PSFTP transfers files much slower than PSCP. |
| 657 | |
| 658 | The throughput of PSFTP 0.54 should be much better than 0.53b and |
| 659 | prior; we've added code to the SFTP backend to queue several blocks |
| 660 | of data rather than waiting for an acknowledgement for each. (The |
| 661 | SCP backend did not suffer from this performance issue because SCP |
| 662 | is a much simpler protocol.) |
| 663 | |
| 664 | \S{faq-bce}{Question} When I run full-colour applications, I see |
| 665 | areas of black space where colour ought to be, or vice versa. |
| 666 | |
| 667 | You almost certainly need to change the \q{Use \i{background colour} to |
| 668 | erase screen} setting in the Terminal panel. If there is too much |
| 669 | black space (the commoner situation), you should enable it, while if |
| 670 | there is too much colour, you should disable it. (See \k{config-erase}.) |
| 671 | |
| 672 | In old versions of PuTTY, this was disabled by default, and would not |
| 673 | take effect until you reset the terminal (see \k{faq-resetterm}). |
| 674 | Since 0.54, it is enabled by default, and changes take effect |
| 675 | immediately. |
| 676 | |
| 677 | \S{faq-resetterm}{Question} When I change some terminal settings, |
| 678 | nothing happens. |
| 679 | |
| 680 | Some of the terminal options (notably \ii{Auto Wrap} and |
| 681 | background-colour screen erase) actually represent the \e{default} |
| 682 | setting, rather than the currently active setting. The server can |
| 683 | send sequences that modify these options in mid-session, but when |
| 684 | the terminal is reset (by server action, or by you choosing \q{Reset |
| 685 | Terminal} from the System menu) the defaults are restored. |
| 686 | |
| 687 | In versions 0.53b and prior, if you change one of these options in |
| 688 | the middle of a session, you will find that the change does not |
| 689 | immediately take effect. It will only take effect once you reset |
| 690 | the terminal. |
| 691 | |
| 692 | In version 0.54, the behaviour has changed - changes to these |
| 693 | settings take effect immediately. |
| 694 | |
| 695 | \S{faq-idleout}{Question} My PuTTY sessions unexpectedly close after |
| 696 | they are \I{idle connections}idle for a while. |
| 697 | |
| 698 | Some types of \i{firewall}, and almost any router doing Network Address |
| 699 | Translation (\i{NAT}, also known as IP masquerading), will forget about |
| 700 | a connection through them if the connection does nothing for too |
| 701 | long. This will cause the connection to be rudely cut off when |
| 702 | contact is resumed. |
| 703 | |
| 704 | You can try to combat this by telling PuTTY to send \e{keepalives}: |
| 705 | packets of data which have no effect on the actual session, but |
| 706 | which reassure the router or firewall that the network connection is |
| 707 | still active and worth remembering about. |
| 708 | |
| 709 | Keepalives don't solve everything, unfortunately; although they |
| 710 | cause greater robustness against this sort of router, they can also |
| 711 | cause a \e{loss} of robustness against network dropouts. See |
| 712 | \k{config-keepalive} in the documentation for more discussion of |
| 713 | this. |
| 714 | |
| 715 | \S{faq-timeout}{Question} PuTTY's network connections time out too |
| 716 | quickly when \I{breaks in connectivity}network connectivity is |
| 717 | temporarily lost. |
| 718 | |
| 719 | This is a Windows problem, not a PuTTY problem. The timeout value |
| 720 | can't be set on per application or per session basis. To increase |
| 721 | the TCP timeout globally, you need to tinker with the Registry. |
| 722 | |
| 723 | On Windows 95, 98 or ME, the registry key you need to create or |
| 724 | change is |
| 725 | |
| 726 | \c HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\ |
| 727 | \c MSTCP\MaxDataRetries |
| 728 | |
| 729 | (it must be of type DWORD in Win95, or String in Win98/ME). |
| 730 | (See MS Knowledge Base article |
| 731 | \W{http://support.microsoft.com/default.aspx?scid=kb;en-us;158474}{158474} |
| 732 | for more information.) |
| 733 | |
| 734 | On Windows NT, 2000, or XP, the registry key to create or change is |
| 735 | |
| 736 | \c HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ |
| 737 | \c Parameters\TcpMaxDataRetransmissions |
| 738 | |
| 739 | and it must be of type DWORD. |
| 740 | (See MS Knowledge Base articles |
| 741 | \W{http://support.microsoft.com/default.aspx?scid=kb;en-us;120642}{120642} |
| 742 | and |
| 743 | \W{http://support.microsoft.com/default.aspx?scid=kb;en-us;314053}{314053} |
| 744 | for more information.) |
| 745 | |
| 746 | Set the key's value to something like 10. This will cause Windows to |
| 747 | try harder to keep connections alive instead of abandoning them. |
| 748 | |
| 749 | \S{faq-puttyputty}{Question} When I \cw{cat} a binary file, I get |
| 750 | \q{PuTTYPuTTYPuTTY} on my command line. |
| 751 | |
| 752 | Don't do that, then. |
| 753 | |
| 754 | This is designed behaviour; when PuTTY receives the character |
| 755 | Control-E from the remote server, it interprets it as a request to |
| 756 | identify itself, and so it sends back the string \q{\cw{PuTTY}} as |
| 757 | if that string had been entered at the keyboard. Control-E should |
| 758 | only be sent by programs that are prepared to deal with the |
| 759 | response. Writing a binary file to your terminal is likely to output |
| 760 | many Control-E characters, and cause this behaviour. Don't do it. |
| 761 | It's a bad plan. |
| 762 | |
| 763 | To mitigate the effects, you could configure the answerback string |
| 764 | to be empty (see \k{config-answerback}); but writing binary files to |
| 765 | your terminal is likely to cause various other unpleasant behaviour, |
| 766 | so this is only a small remedy. |
| 767 | |
| 768 | \S{faq-wintitle}{Question} When I \cw{cat} a binary file, my \i{window |
| 769 | title} changes to a nonsense string. |
| 770 | |
| 771 | Don't do that, then. |
| 772 | |
| 773 | It is designed behaviour that PuTTY should have the ability to |
| 774 | adjust the window title on instructions from the server. Normally |
| 775 | the control sequence that does this should only be sent |
| 776 | deliberately, by programs that know what they are doing and intend |
| 777 | to put meaningful text in the window title. Writing a binary file to |
| 778 | your terminal runs the risk of sending the same control sequence by |
| 779 | accident, and cause unexpected changes in the window title. Don't do |
| 780 | it. |
| 781 | |
| 782 | \S{faq-password-fails}{Question} My keyboard stops working once |
| 783 | PuTTY displays the password prompt. |
| 784 | |
| 785 | No, it doesn't. PuTTY just doesn't display the password you type, so |
| 786 | that someone looking at your screen can't see what it is. |
| 787 | |
| 788 | Unlike the Windows login prompts, PuTTY doesn't display the password |
| 789 | as a row of asterisks either. This is so that someone looking at |
| 790 | your screen can't even tell how \e{long} your password is, which |
| 791 | might be valuable information. |
| 792 | |
| 793 | \S{faq-keyboard}{Question} One or more function keys don't do what I |
| 794 | expected in a server-side application. |
| 795 | |
| 796 | If you've already tried all the relevant options in the PuTTY |
| 797 | Keyboard panel, you may need to mail the PuTTY maintainers and ask. |
| 798 | |
| 799 | It is \e{not} usually helpful just to tell us which application, |
| 800 | which server operating system, and which key isn't working; in order |
| 801 | to replicate the problem we would need to have a copy of every |
| 802 | operating system, and every application, that anyone has ever |
| 803 | complained about. |
| 804 | |
| 805 | PuTTY responds to function key presses by sending a sequence of |
| 806 | control characters to the server. If a function key isn't doing what |
| 807 | you expect, it's likely that the character sequence your application |
| 808 | is expecting to receive is not the same as the one PuTTY is sending. |
| 809 | Therefore what we really need to know is \e{what} sequence the |
| 810 | application is expecting. |
| 811 | |
| 812 | The simplest way to investigate this is to find some other terminal |
| 813 | environment, in which that function key \e{does} work; and then |
| 814 | investigate what sequence the function key is sending in that |
| 815 | situation. One reasonably easy way to do this on a Unix system is to |
| 816 | type the command \c{cat}, and then press the function key. This is |
| 817 | likely to produce output of the form \c{^[[11~}. You can also do |
| 818 | this in PuTTY, to find out what sequence the function key is |
| 819 | producing in that. Then you can mail the PuTTY maintainers and tell |
| 820 | us \q{I wanted the F1 key to send \c{^[[11~}, but instead it's |
| 821 | sending \c{^[OP}, can this be done?}, or something similar. |
| 822 | |
| 823 | You should still read the |
| 824 | \W{http://www.chiark.greenend.org.uk/~sgtatham/putty/feedback.html}{Feedback |
| 825 | page} on the PuTTY website (also provided as \k{feedback} in the |
| 826 | manual), and follow the guidelines contained in that. |
| 827 | |
| 828 | \S{faq-openssh-bad-openssl}{Question} Since my SSH server was upgraded |
| 829 | to \i{OpenSSH} 3.1p1/3.4p1, I can no longer connect with PuTTY. |
| 830 | |
| 831 | There is a known problem when OpenSSH has been built against an |
| 832 | incorrect version of OpenSSL; the quick workaround is to configure |
| 833 | PuTTY to use SSH protocol 2 and the Blowfish cipher. |
| 834 | |
| 835 | For more details and OpenSSH patches, see |
| 836 | \W{http://bugzilla.mindrot.org/show_bug.cgi?id=138}{bug 138} in the |
| 837 | OpenSSH BTS. |
| 838 | |
| 839 | This is not a PuTTY-specific problem; if you try to connect with |
| 840 | another client you'll likely have similar problems. (Although PuTTY's |
| 841 | default cipher differs from many other clients.) |
| 842 | |
| 843 | \e{OpenSSH 3.1p1:} configurations known to be broken (and symptoms): |
| 844 | |
| 845 | \b SSH-2 with AES cipher (PuTTY says \q{Assertion failed! Expression: |
| 846 | (len & 15) == 0} in \cw{sshaes.c}, or \q{Out of memory}, or crashes) |
| 847 | |
| 848 | \b SSH-2 with 3DES (PuTTY says \q{Incorrect MAC received on packet}) |
| 849 | |
| 850 | \b SSH-1 with Blowfish (PuTTY says \q{Incorrect CRC received on |
| 851 | packet}) |
| 852 | |
| 853 | \b SSH-1 with 3DES |
| 854 | |
| 855 | \e{OpenSSH 3.4p1:} as of 3.4p1, only the problem with SSH-1 and |
| 856 | Blowfish remains. Rebuild your server, apply the patch linked to from |
| 857 | bug 138 above, or use another cipher (e.g., 3DES) instead. |
| 858 | |
| 859 | \e{Other versions:} we occasionally get reports of the same symptom |
| 860 | and workarounds with older versions of OpenSSH, although it's not |
| 861 | clear the underlying cause is the same. |
| 862 | |
| 863 | \S{faq-ssh2key-ssh1conn}{Question} Why do I see \q{Couldn't load |
| 864 | private key from ...}? Why can PuTTYgen load my key but not PuTTY? |
| 865 | |
| 866 | It's likely that you've generated an SSH protocol 2 key with PuTTYgen, |
| 867 | but you're trying to use it in an SSH-1 connection. SSH-1 and SSH-2 keys |
| 868 | have different formats, and (at least in 0.52) PuTTY's reporting of a |
| 869 | key in the wrong format isn't optimal. |
| 870 | |
| 871 | To connect using SSH-2 to a server that supports both versions, you |
| 872 | need to change the configuration from the default (see \k{faq-ssh2}). |
| 873 | |
| 874 | \S{faq-rh8-utf8}{Question} When I'm connected to a \i{Red Hat Linux} 8.0 |
| 875 | system, some characters don't display properly. |
| 876 | |
| 877 | A common complaint is that hyphens in man pages show up as a-acute. |
| 878 | |
| 879 | With release 8.0, Red Hat appear to have made \i{UTF-8} the default |
| 880 | character set. There appears to be no way for terminal emulators such |
| 881 | as PuTTY to know this (as far as we know, the appropriate escape |
| 882 | sequence to switch into UTF-8 mode isn't sent). |
| 883 | |
| 884 | A fix is to configure sessions to RH8 systems to use UTF-8 |
| 885 | translation - see \k{config-charset} in the documentation. (Note that |
| 886 | if you use \q{Change Settings}, changes may not take place immediately |
| 887 | - see \k{faq-resetterm}.) |
| 888 | |
| 889 | If you really want to change the character set used by the server, the |
| 890 | right place is \c{/etc/sysconfig/i18n}, but this shouldn't be |
| 891 | necessary. |
| 892 | |
| 893 | \S{faq-screen}{Question} Since I upgraded to PuTTY 0.54, the |
| 894 | scrollback has stopped working when I run \c{screen}. |
| 895 | |
| 896 | PuTTY's terminal emulator has always had the policy that when the |
| 897 | \q{\i{alternate screen}} is in use, nothing is added to the scrollback. |
| 898 | This is because the usual sorts of programs which use the alternate |
| 899 | screen are things like text editors, which tend to scroll back and |
| 900 | forth in the same document a lot; so (a) they would fill up the |
| 901 | scrollback with a large amount of unhelpfully disordered text, and |
| 902 | (b) they contain their \e{own} method for the user to scroll back to |
| 903 | the bit they were interested in. We have generally found this policy |
| 904 | to do the Right Thing in almost all situations. |
| 905 | |
| 906 | Unfortunately, \c{screen} is one exception: it uses the alternate |
| 907 | screen, but it's still usually helpful to have PuTTY's scrollback |
| 908 | continue working. The simplest solution is to go to the Features |
| 909 | control panel and tick \q{Disable switching to alternate terminal |
| 910 | screen}. (See \k{config-features-altscreen} for more details.) |
| 911 | Alternatively, you can tell \c{screen} itself not to use the |
| 912 | alternate screen: the |
| 913 | \W{http://www4.informatik.uni-erlangen.de/~jnweiger/screen-faq.html}{\c{screen} |
| 914 | FAQ} suggests adding the line \cq{termcapinfo xterm ti@:te@} to your |
| 915 | \cw{.screenrc} file. |
| 916 | |
| 917 | The reason why this only started to be a problem in 0.54 is because |
| 918 | \c{screen} typically uses an unusual control sequence to switch to |
| 919 | the alternate screen, and previous versions of PuTTY did not support |
| 920 | this sequence. |
| 921 | |
| 922 | \S{faq-alternate-localhost}{Question} Since I upgraded \i{Windows XP} |
| 923 | to Service Pack 2, I can't use addresses like \cw{127.0.0.2}. |
| 924 | |
| 925 | Some people who ask PuTTY to listen on \i{localhost} addresses other |
| 926 | than \cw{127.0.0.1} to forward services such as \i{SMB} and \i{Windows |
| 927 | Terminal Services} have found that doing so no longer works since |
| 928 | they upgraded to WinXP SP2. |
| 929 | |
| 930 | This is apparently an issue with SP2 that is acknowledged by Microsoft |
| 931 | in MS Knowledge Base article |
| 932 | \W{http://support.microsoft.com/default.aspx?scid=kb;en-us;884020}{884020}. |
| 933 | The article links to a fix you can download. |
| 934 | |
| 935 | (\e{However}, we've been told that SP2 \e{also} fixes the bug that |
| 936 | means you need to use non-\cw{127.0.0.1} addresses to forward |
| 937 | Terminal Services in the first place.) |
| 938 | |
| 939 | \S{faq-missing-slash}{Question} PSFTP commands seem to be missing a |
| 940 | directory separator (slash). |
| 941 | |
| 942 | Some people have reported the following incorrect behaviour with |
| 943 | PSFTP: |
| 944 | |
| 945 | \c psftp> pwd |
| 946 | \e iii |
| 947 | \c Remote directory is /dir1/dir2 |
| 948 | \c psftp> get filename.ext |
| 949 | \e iiiiiiiiiiiiiiii |
| 950 | \c /dir1/dir2filename.ext: no such file or directory |
| 951 | |
| 952 | This is not a bug in PSFTP. There is a known bug in some versions of |
| 953 | portable \i{OpenSSH} |
| 954 | (\W{http://bugzilla.mindrot.org/show_bug.cgi?id=697}{bug 697}) that |
| 955 | causes these symptoms; it appears to have been introduced around |
| 956 | 3.7.x. It manifests only on certain platforms (AIX is what has been |
| 957 | reported to us). |
| 958 | |
| 959 | There is a patch for OpenSSH attached to that bug; it's also fixed in |
| 960 | recent versions of portable OpenSSH (from around 3.8). |
| 961 | |
| 962 | \S{faq-connaborted}{Question} Do you want to hear about \q{Software |
| 963 | caused connection abort}? |
| 964 | |
| 965 | In the documentation for PuTTY 0.53 and 0.53b, we mentioned that we'd |
| 966 | like to hear about any occurrences of this error. Since the release |
| 967 | of PuTTY 0.54, however, we've been convinced that this error doesn't |
| 968 | indicate that PuTTY's doing anything wrong, and we don't need to hear |
| 969 | about further occurrences. See \k{errors-connaborted} for our current |
| 970 | documentation of this error. |
| 971 | |
| 972 | \S{faq-rekey}{Question} My SSH-2 session \I{locking up, SSH-2 |
| 973 | sessions}locks up for a few seconds every so often. |
| 974 | |
| 975 | Recent versions of PuTTY automatically initiate \i{repeat key |
| 976 | exchange} once per hour, to improve session security. If your client |
| 977 | or server machine is slow, you may experience this as a delay of |
| 978 | anything up to thirty seconds or so. |
| 979 | |
| 980 | These \I{delays, in SSH-2 sessions}delays are inconvenient, but they |
| 981 | are there for your protection. If they really cause you a problem, |
| 982 | you can choose to turn off periodic rekeying using the \q{Kex} |
| 983 | configuration panel (see \k{config-ssh-kex}), but be aware that you |
| 984 | will be sacrificing security for this. (Falling back to SSH-1 would |
| 985 | also remove the delays, but would lose a \e{lot} more security |
| 986 | still. We do not recommend it.) |
| 987 | |
| 988 | \H{faq-secure} Security questions |
| 989 | |
| 990 | \S{faq-publicpc}{Question} Is it safe for me to download PuTTY and |
| 991 | use it on a public PC? |
| 992 | |
| 993 | It depends on whether you trust that PC. If you don't trust the |
| 994 | public PC, don't use PuTTY on it, and don't use any other software |
| 995 | you plan to type passwords into either. It might be watching your |
| 996 | keystrokes, or it might tamper with the PuTTY binary you download. |
| 997 | There is \e{no} program safe enough that you can run it on an |
| 998 | actively malicious PC and get away with typing passwords into it. |
| 999 | |
| 1000 | If you do trust the PC, then it's probably OK to use PuTTY on it |
| 1001 | (but if you don't trust the network, then the PuTTY download might |
| 1002 | be tampered with, so it would be better to carry PuTTY with you on a |
| 1003 | floppy). |
| 1004 | |
| 1005 | \S{faq-cleanup}{Question} What does PuTTY leave on a system? How can |
| 1006 | I \i{clean up} after it? |
| 1007 | |
| 1008 | PuTTY will leave some Registry entries, and a random seed file, on |
| 1009 | the PC (see \k{faq-settings}). If you are using PuTTY on a public |
| 1010 | PC, or somebody else's PC, you might want to clean these up when you |
| 1011 | leave. You can do that automatically, by running the command |
| 1012 | \c{putty -cleanup}. (Note that this only removes settings for |
| 1013 | the currently logged-in user on \i{multi-user systems}.) |
| 1014 | |
| 1015 | If PuTTY was installed from the installer package, it will also |
| 1016 | appear in \q{Add/Remove Programs}. Older versions of the uninstaller |
| 1017 | do not remove the above-mentioned registry entries and file. |
| 1018 | |
| 1019 | \S{faq-dsa}{Question} How come PuTTY now supports \i{DSA}, when the |
| 1020 | website used to say how insecure it was? |
| 1021 | |
| 1022 | DSA has a major weakness \e{if badly implemented}: it relies on a |
| 1023 | random number generator to far too great an extent. If the random |
| 1024 | number generator produces a number an attacker can predict, the DSA |
| 1025 | private key is exposed - meaning that the attacker can log in as you |
| 1026 | on all systems that accept that key. |
| 1027 | |
| 1028 | The PuTTY policy changed because the developers were informed of |
| 1029 | ways to implement DSA which do not suffer nearly as badly from this |
| 1030 | weakness, and indeed which don't need to rely on random numbers at |
| 1031 | all. For this reason we now believe PuTTY's DSA implementation is |
| 1032 | probably OK. However, if you have the choice, we still recommend you |
| 1033 | use RSA instead. |
| 1034 | |
| 1035 | \S{faq-virtuallock}{Question} Couldn't Pageant use |
| 1036 | \cw{VirtualLock()} to stop private keys being written to disk? |
| 1037 | |
| 1038 | Unfortunately not. The \cw{VirtualLock()} function in the Windows |
| 1039 | API doesn't do a proper job: it may prevent small pieces of a |
| 1040 | process's memory from being paged to disk while the process is |
| 1041 | running, but it doesn't stop the process's memory as a whole from |
| 1042 | being swapped completely out to disk when the process is long-term |
| 1043 | inactive. And Pageant spends most of its time inactive. |
| 1044 | |
| 1045 | \H{faq-admin} Administrative questions |
| 1046 | |
| 1047 | \S{faq-domain}{Question} Would you like me to register you a nicer |
| 1048 | domain name? |
| 1049 | |
| 1050 | No, thank you. Even if you can find one (most of them seem to have |
| 1051 | been registered already, by people who didn't ask whether we |
| 1052 | actually wanted it before they applied), we're happy with the PuTTY |
| 1053 | web site being exactly where it is. It's not hard to find (just type |
| 1054 | \q{putty} into \W{http://www.google.com/}{google.com} and we're the |
| 1055 | first link returned), and we don't believe the administrative hassle |
| 1056 | of moving the site would be worth the benefit. |
| 1057 | |
| 1058 | In addition, if we \e{did} want a custom domain name, we would want |
| 1059 | to run it ourselves, so we knew for certain that it would continue |
| 1060 | to point where we wanted it, and wouldn't suddenly change or do |
| 1061 | strange things. Having it registered for us by a third party who we |
| 1062 | don't even know is not the best way to achieve this. |
| 1063 | |
| 1064 | \S{faq-webhosting}{Question} Would you like free web hosting for the |
| 1065 | PuTTY web site? |
| 1066 | |
| 1067 | We already have some, thanks. |
| 1068 | |
| 1069 | \S{faq-link}{Question} Would you link to my web site from the PuTTY |
| 1070 | web site? |
| 1071 | |
| 1072 | Only if the content of your web page is of definite direct interest |
| 1073 | to PuTTY users. If your content is unrelated, or only tangentially |
| 1074 | related, to PuTTY, then the link would simply be advertising for |
| 1075 | you. |
| 1076 | |
| 1077 | One very nice effect of the Google ranking mechanism is that by and |
| 1078 | large, the most popular web sites get the highest rankings. This |
| 1079 | means that when an ordinary person does a search, the top item in |
| 1080 | the search is very likely to be a high-quality site or the site they |
| 1081 | actually wanted, rather than the site which paid the most money for |
| 1082 | its ranking. |
| 1083 | |
| 1084 | The PuTTY web site is held in high esteem by Google, for precisely |
| 1085 | this reason: lots of people have linked to it simply because they |
| 1086 | like PuTTY, without us ever having to ask anyone to link to us. We |
| 1087 | feel that it would be an abuse of this esteem to use it to boost the |
| 1088 | ranking of random advertisers' web sites. If you want your web site |
| 1089 | to have a high Google ranking, we'd prefer that you achieve this the |
| 1090 | way we did - by being good enough at what you do that people will |
| 1091 | link to you simply because they like you. |
| 1092 | |
| 1093 | In particular, we aren't interested in trading links for money (see |
| 1094 | above), and we \e{certainly} aren't interested in trading links for |
| 1095 | other links (since we have no advertising on our web site, our |
| 1096 | Google ranking is not even directly worth anything to us). If we |
| 1097 | don't want to link to you for free, then we probably won't want to |
| 1098 | link to you at all. |
| 1099 | |
| 1100 | If you have software based on PuTTY, or specifically designed to |
| 1101 | interoperate with PuTTY, or in some other way of genuine interest to |
| 1102 | PuTTY users, then we will probably be happy to add a link to you on |
| 1103 | our Links page. And if you're running a mirror of the PuTTY web |
| 1104 | site, we're \e{definitely} interested. |
| 1105 | |
| 1106 | \S{faq-sourceforge}{Question} Why don't you move PuTTY to |
| 1107 | SourceForge? |
| 1108 | |
| 1109 | Partly, because we don't want to move the web site location (see |
| 1110 | \k{faq-domain}). |
| 1111 | |
| 1112 | Also, security reasons. PuTTY is a security product, and as such it |
| 1113 | is particularly important to guard the code and the web site against |
| 1114 | unauthorised modifications which might introduce subtle security |
| 1115 | flaws. Therefore, we prefer that the Subversion repository, web site and |
| 1116 | FTP site remain where they are, under the direct control of system |
| 1117 | administrators we know and trust personally, rather than being run |
| 1118 | by a large organisation full of people we've never met and which is |
| 1119 | known to have had breakins in the past. |
| 1120 | |
| 1121 | No offence to SourceForge; I think they do a wonderful job. But |
| 1122 | they're not ideal for everyone, and in particular they're not ideal |
| 1123 | for us. |
| 1124 | |
| 1125 | \S{faq-mailinglist1}{Question} Why can't I subscribe to the |
| 1126 | putty-bugs mailing list? |
| 1127 | |
| 1128 | Because you're not a member of the PuTTY core development team. The |
| 1129 | putty-bugs mailing list is not a general newsgroup-like discussion |
| 1130 | forum; it's a contact address for the core developers, and an |
| 1131 | \e{internal} mailing list for us to discuss things among ourselves. |
| 1132 | If we opened it up for everybody to subscribe to, it would turn into |
| 1133 | something more like a newsgroup and we would be completely |
| 1134 | overwhelmed by the volume of traffic. It's hard enough to keep up |
| 1135 | with the list as it is. |
| 1136 | |
| 1137 | \S{faq-mailinglist2}{Question} If putty-bugs isn't a |
| 1138 | general-subscription mailing list, what is? |
| 1139 | |
| 1140 | There isn't one, that we know of. |
| 1141 | |
| 1142 | If someone else wants to set up a mailing list or other forum for |
| 1143 | PuTTY users to help each other with common problems, that would be |
| 1144 | fine with us, though the PuTTY team would almost certainly not have the |
| 1145 | time to read it. It's probably better to use one of the established |
| 1146 | newsgroups for this purpose (see \k{feedback-other-fora}). |
| 1147 | |
| 1148 | \S{faq-donations}{Question} How can I donate to PuTTY development? |
| 1149 | |
| 1150 | Please, \e{please} don't feel you have to. PuTTY is completely free |
| 1151 | software, and not shareware. We think it's very important that |
| 1152 | \e{everybody} who wants to use PuTTY should be able to, whether they |
| 1153 | have any money or not; so the last thing we would want is for a |
| 1154 | PuTTY user to feel guilty because they haven't paid us any money. If |
| 1155 | you want to keep your money, please do keep it. We wouldn't dream of |
| 1156 | asking for any. |
| 1157 | |
| 1158 | Having said all that, if you still really \e{want} to give us money, |
| 1159 | we won't argue :-) The easiest way for us to accept donations is if |
| 1160 | you send money to \cw{<anakin@pobox.com>} using PayPal |
| 1161 | (\W{http://www.paypal.com/}\cw{www.paypal.com}). Alternatively, if |
| 1162 | you don't trust PayPal, you could donate through e-gold |
| 1163 | (\W{http://www.e-gold.com}\cw{www.e-gold.com}): deposit your |
| 1164 | donation in account number 174769, then send us e-mail to let us |
| 1165 | know you've done so (otherwise we might not notice for months!). |
| 1166 | |
| 1167 | Small donations (tens of dollars or tens of euros) will probably be |
| 1168 | spent on beer or curry, which helps motivate our volunteer team to |
| 1169 | continue doing this for the world. Larger donations will be spent on |
| 1170 | something that actually helps development, if we can find anything |
| 1171 | (perhaps new hardware, or a copy of Windows XP), but if we can't |
| 1172 | find anything then we'll just distribute the money among the |
| 1173 | developers. If you want to be sure your donation is going towards |
| 1174 | something worthwhile, ask us first. If you don't like these terms, |
| 1175 | feel perfectly free not to donate. We don't mind. |
| 1176 | |
| 1177 | \S{faq-permission}{Question} Can I have permission to put PuTTY on a |
| 1178 | cover disk / distribute it with other software / etc? |
| 1179 | |
| 1180 | Yes. You need not bother asking us explicitly for permission. You |
| 1181 | already have permission. Redistribution of the unmodified PuTTY |
| 1182 | binary in this way is entirely permitted by our licence (see |
| 1183 | \k{licence}), and you are welcome to do it as much as you like. |
| 1184 | |
| 1185 | If you are distributing PuTTY within your own organisation, or for |
| 1186 | use with your own product, then we recommend (but do not insist) |
| 1187 | that you offer your own first-line technical support, to answer |
| 1188 | questions directly relating to the interaction of PuTTY with your |
| 1189 | particular environment. If your users mail us directly, we won't be |
| 1190 | able to give them very much help about things specific to your own |
| 1191 | setup. |
| 1192 | |
| 1193 | \H{faq-misc} Miscellaneous questions |
| 1194 | |
| 1195 | \S{faq-openssh}{Question} Is PuTTY a port of \i{OpenSSH}, or based on |
| 1196 | OpenSSH? |
| 1197 | |
| 1198 | No, it isn't. PuTTY is almost completely composed of code written |
| 1199 | from scratch for PuTTY. The only code we share with OpenSSH is the |
| 1200 | detector for SSH-1 CRC compensation attacks, written by CORE SDI S.A. |
| 1201 | |
| 1202 | \S{faq-sillyputty}{Question} Where can I buy silly putty? |
| 1203 | |
| 1204 | You're looking at the wrong web site; the only PuTTY we know about |
| 1205 | here is the name of a computer program. |
| 1206 | |
| 1207 | If you want the kind of putty you can buy as an executive toy, the |
| 1208 | PuTTY team can personally recommend Thinking Putty, which you can |
| 1209 | buy from Crazy Aaron's Putty World, at |
| 1210 | \W{http://www.puttyworld.com}\cw{www.puttyworld.com}. |
| 1211 | |
| 1212 | \S{faq-meaning}{Question} What does \q{PuTTY} mean? |
| 1213 | |
| 1214 | It's the name of a popular SSH and Telnet client. Any other meaning |
| 1215 | is in the eye of the beholder. It's been rumoured that \q{PuTTY} |
| 1216 | is the antonym of \q{\cw{getty}}, or that it's the stuff that makes your |
| 1217 | Windows useful, or that it's a kind of plutonium Teletype. We |
| 1218 | couldn't possibly comment on such allegations. |
| 1219 | |
| 1220 | \S{faq-pronounce}{Question} How do I pronounce \q{PuTTY}? |
| 1221 | |
| 1222 | Exactly like the English word \q{putty}, which we pronounce |
| 1223 | /\u02C8{'}p\u028C{V}ti/. |