forked from Yasushi/putty
-
Notifications
You must be signed in to change notification settings - Fork 7
/
Copy pathfaq.but
1556 lines (1211 loc) · 69.1 KB
/
faq.but
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
\A{faq} PuTTY \i{FAQ}
This FAQ is published on the PuTTY web site, and also provided as an
appendix in the manual.
\H{faq-intro} Introduction
\S{faq-what}{Question} What is PuTTY?
PuTTY is a client program for the SSH, Telnet and Rlogin network
protocols.
These protocols are all used to run a remote session on a computer,
over a network. PuTTY implements the client end of that session: the
end at which the session is displayed, rather than the end at which
it runs.
In really simple terms: you run PuTTY on a Windows machine, and tell
it to connect to (for example) a Unix machine. PuTTY opens a window.
Then, anything you type into that window is sent straight to the
Unix machine, and everything the Unix machine sends back is
displayed in the window. So you can work on the Unix machine as if
you were sitting at its console, while actually sitting somewhere
else.
\H{faq-support} Features supported in PuTTY
\I{supported features}In general, if you want to know if PuTTY supports
a particular feature, you should look for it on the
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/}{PuTTY web site}.
In particular:
\b try the
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html}{changes
page}, and see if you can find the feature on there. If a feature is
listed there, it's been implemented. If it's listed as a change made
\e{since} the latest version, it should be available in the
development snapshots, in which case testing will be very welcome.
\b try the
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/}{Wishlist
page}, and see if you can find the feature there. If it's on there,
and not in the \q{Recently fixed} section, it probably \e{hasn't} been
implemented.
\S{faq-ssh2}{Question} Does PuTTY support SSH-2?
Yes. SSH-2 support has been available in PuTTY since version 0.50.
Public key authentication (both RSA and DSA) in SSH-2 is new in
version 0.52.
\S{faq-ssh2-keyfmt}{Question} Does PuTTY support reading OpenSSH or
\cw{ssh.com} SSH-2 private key files?
PuTTY doesn't support this natively (see
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/key-formats-natively.html}{the wishlist entry}
for reasons why not), but as of 0.53
PuTTYgen can convert both OpenSSH and \cw{ssh.com} private key
files into PuTTY's format.
\S{faq-ssh1}{Question} Does PuTTY support SSH-1?
Yes. SSH-1 support has always been available in PuTTY.
However, the SSH-1 protocol has many weaknesses and is no longer
considered secure; it should be avoided if at all possible.
\S{faq-localecho}{Question} Does PuTTY support \i{local echo}?
Yes. Version 0.52 has proper support for local echo.
In version 0.51 and before, local echo could not be separated from
local line editing (where you type a line of text locally, and it is
not sent to the server until you press Return, so you have the
chance to edit it and correct mistakes \e{before} the server sees
it). New in version 0.52, local echo and local line editing are
separate options, and by default PuTTY will try to determine
automatically whether to enable them or not, based on which protocol
you have selected and also based on hints from the server. If you
have a problem with PuTTY's default choice, you can force each
option to be enabled or disabled as you choose. The controls are in
the Terminal panel, in the section marked \q{Line discipline
options}.
\S{faq-savedsettings}{Question} Does PuTTY support storing settings,
so I don't have to change them every time?
Yes, all of PuTTY's settings can be saved in named session profiles.
You can also change the default settings that are used for new sessions.
See \k{config-saving} in the documentation for how to do this.
\S{faq-disksettings}{Question} Does PuTTY support storing its
settings in a disk file?
Not at present, although \k{config-file} in the documentation gives
a method of achieving the same effect.
\S{faq-fullscreen}{Question} Does PuTTY support full-screen mode,
like a DOS box?
Yes; this is a new feature in version 0.52.
\S{faq-password-remember}{Question} Does PuTTY have the ability to
\i{remember my password} so I don't have to type it every time?
No, it doesn't.
Remembering your password is a bad plan for obvious security
reasons: anyone who gains access to your machine while you're away
from your desk can find out the remembered password, and use it,
abuse it or change it.
In addition, it's not even \e{possible} for PuTTY to automatically
send your password in a Telnet session, because Telnet doesn't give
the client software any indication of which part of the login
process is the password prompt. PuTTY would have to guess, by
looking for words like \q{password} in the session data; and if your
login program is written in something other than English, this won't
work.
In SSH, remembering your password would be possible in theory, but
there doesn't seem to be much point since SSH supports public key
authentication, which is more flexible and more secure. See
\k{pubkey} in the documentation for a full discussion of public key
authentication.
\S{faq-hostkeys}{Question} Is there an option to turn off the
\I{verifying the host key}annoying host key prompts?
No, there isn't. And there won't be. Even if you write it yourself
and send us the patch, we won't accept it.
Those annoying host key prompts are the \e{whole point} of SSH.
Without them, all the cryptographic technology SSH uses to secure
your session is doing nothing more than making an attacker's job
slightly harder; instead of sitting between you and the server with
a packet sniffer, the attacker must actually subvert a router and
start modifying the packets going back and forth. But that's not all
that much harder than just sniffing; and without host key checking,
it will go completely undetected by client or server.
Host key checking is your guarantee that the encryption you put on
your data at the client end is the \e{same} encryption taken off the
data at the server end; it's your guarantee that it hasn't been
removed and replaced somewhere on the way. Host key checking makes
the attacker's job \e{astronomically} hard, compared to packet
sniffing, and even compared to subverting a router. Instead of
applying a little intelligence and keeping an eye on Bugtraq, the
attacker must now perform a brute-force attack against at least one
military-strength cipher. That insignificant host key prompt really
does make \e{that} much difference.
If you're having a specific problem with host key checking - perhaps
you want an automated batch job to make use of PSCP or Plink, and the
interactive host key prompt is hanging the batch process - then the
right way to fix it is to add the correct host key to the Registry in
advance, or if the Registry is not available, to use the \cw{-hostkey}
command-line option. That way, you retain the \e{important} feature of
host key checking: the right key will be accepted and the wrong ones
will not. Adding an option to turn host key checking off completely is
the wrong solution and we will not do it.
If you have host keys available in the common \i\c{known_hosts} format,
we have a script called
\W{http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=blob;f=contrib/kh2reg.py;hb=HEAD}\c{kh2reg.py}
to convert them to a Windows .REG file, which can be installed ahead of
time by double-clicking or using \c{REGEDIT}.
\S{faq-server}{Question} Will you write an SSH server for the PuTTY
suite, to go with the client?
No. The only reason we might want to would be if we could easily
re-use existing code and significantly cut down the effort. We don't
believe this is the case; there just isn't enough common ground
between an SSH client and server to make it worthwhile.
If someone else wants to use bits of PuTTY in the process of writing
a Windows SSH server, they'd be perfectly welcome to of course, but
I really can't see it being a lot less effort for us to do that than
it would be for us to write a server from the ground up. We don't
have time, and we don't have motivation. The code is available if
anyone else wants to try it.
\S{faq-pscp-ascii}{Question} Can PSCP or PSFTP transfer files in
\i{ASCII} mode?
Unfortunately not.
Until recently, this was a limitation of the file transfer protocols:
the SCP and SFTP protocols had no notion of transferring a file in
anything other than binary mode. (This is still true of SCP.)
The current draft protocol spec of SFTP proposes a means of
implementing ASCII transfer. At some point PSCP/PSFTP may implement
this proposal.
\H{faq-ports} Ports to other operating systems
The eventual goal is for PuTTY to be a multi-platform program, able
to run on at least Windows, Mac OS and Unix.
Porting will become easier once PuTTY has a generalised porting
layer, drawing a clear line between platform-dependent and
platform-independent code. The general intention was for this
porting layer to evolve naturally as part of the process of doing
the first port; a Unix port has now been released and the plan
seems to be working so far.
\S{faq-ports-general}{Question} What ports of PuTTY exist?
Currently, release versions of PuTTY tools only run on full Win32
systems and Unix. \q{\i{Win32}} includes versions of Windows from
Windows 95 onwards (as opposed to the 16-bit Windows 3.1; see
\k{faq-win31}), up to and including Windows 7; and we know of no
reason why PuTTY should not continue to work on future versions
of Windows.
The Windows executables we provide are for the 32-bit \q{\i{x86}}
processor architecture, but they should work fine on 64-bit
processors that are backward-compatible with that architecture.
(We used to also provide executables for Windows for the Alpha
processor, but stopped after 0.58 due to lack of interest.)
In the development code, partial ports to the Mac OSes exist (see
\k{faq-mac-port}).
Currently PuTTY does \e{not} run on Windows CE (see \k{faq-wince}).
We do not have release-quality ports for any other systems at the
present time. If anyone told you we had an EPOC port, or an iPaq port,
or any other port of PuTTY, they were mistaken. We don't.
There are some third-party ports to various platforms, mentioned
on the
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/links.html}{Links page of our website}.
\S{faq-unix}{Question} \I{Unix version}Is there a port to Unix?
As of 0.54, there are Unix ports of most of the traditional PuTTY
tools, and also one entirely new application.
If you look at the source release, you should find a \c{unix}
subdirectory. There are a couple of ways of building it,
including the usual \c{configure}/\c{make}; see the file \c{README}
in the source distribution. This should build you Unix
ports of Plink, PuTTY itself, PuTTYgen, PSCP, PSFTP, and also
\i\c{pterm} - an \cw{xterm}-type program which supports the same
terminal emulation as PuTTY. We do not yet have a Unix port of
Pageant.
If you don't have \i{Gtk}, you should still be able to build the
command-line tools.
Note that Unix PuTTY has mostly only been tested on Linux so far;
portability problems such as BSD-style ptys or different header file
requirements are expected.
\S{faq-unix-why}{Question} What's the point of the Unix port? Unix
has OpenSSH.
All sorts of little things. \c{pterm} is directly useful to anyone
who prefers PuTTY's terminal emulation to \c{xterm}'s, which at
least some people do. Unix Plink has apparently found a niche among
people who find the complexity of OpenSSL makes OpenSSH hard to
install (and who don't mind Plink not having as many features). Some
users want to generate a large number of SSH keys on Unix and then
copy them all into PuTTY, and the Unix PuTTYgen should allow them to
automate that conversion process.
There were development advantages as well; porting PuTTY to Unix was
a valuable path-finding effort for other future ports, and also
allowed us to use the excellent Linux tool
\W{http://valgrind.kde.org/}{Valgrind} to help with debugging, which
has already improved PuTTY's stability on \e{all} platforms.
However, if you're a Unix user and you can see no reason to switch
from OpenSSH to PuTTY/Plink, then you're probably right. We don't
expect our Unix port to be the right thing for everybody.
\S{faq-wince}{Question} Will there be a port to Windows CE or PocketPC?
We have done some work on such a port, but it only reached an early
stage, and certainly not a useful one. It's no longer being actively
worked on.
However, there's a third-party port at
\W{http://www.pocketputty.net/}\c{http://www.pocketputty.net/}.
\S{faq-win31}{Question} Is there a port to \i{Windows 3.1}?
PuTTY is a 32-bit application from the ground up, so it won't run on
Windows 3.1 as a native 16-bit program; and it would be \e{very}
hard to port it to do so, because of Windows 3.1's vile memory
allocation mechanisms.
However, it is possible in theory to compile the existing PuTTY
source in such a way that it will run under \i{Win32s} (an extension to
Windows 3.1 to let you run 32-bit programs). In order to do this
you'll need the right kind of C compiler - modern versions of Visual
C at least have stopped being backwards compatible to Win32s. Also,
the last time we tried this it didn't work very well.
If you're interested in running PuTTY under Windows 3.1, help and
testing in this area would be very welcome!
\S{faq-mac-port}{Question} Will there be a port to the \I{Mac OS}Mac?
There are several answers to this question:
\b The Unix/Gtk port is already fully working under Mac OS X as an X11
application.
\b A native (Cocoa) Mac OS X port has been started. It's just about
usable, but is of nowhere near release quality yet, and is likely to
behave in unexpected ways. Currently it's unlikely to be completed
unless someone steps in to help.
\b A separate port to the classic Mac OS (pre-OSX) is also in
progress; it too is not ready yet.
\S{faq-epoc}{Question} Will there be a port to EPOC?
I hope so, but given that ports aren't really progressing very fast
even on systems the developers \e{do} already know how to program
for, it might be a long time before any of us get round to learning
a new system and doing the port for that.
However, some of the work has been done by other people; see the
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/links.html}{Links page of our website}
for various third-party ports.
\S{faq-iphone}{Question} Will there be a port to the iPhone?
We have no plans to write such a port ourselves; none of us has an
iPhone, and developing and publishing applications for it looks
awkward and expensive. Such a port would probably depend upon the
stalled Mac OS X port (see \k{faq-mac-port}).
However, there is a third-party SSH client for the iPhone and
iPod\_Touch called \W{http://www.instantcocoa.com/products/pTerm/}{pTerm},
which is apparently based on PuTTY. (This is nothing to do with our
similarly-named \c{pterm}, which is a standalone terminal emulator for
Unix systems; see \k{faq-unix}.)
\H{faq-embedding} Embedding PuTTY in other programs
\S{faq-dll}{Question} Is the SSH or Telnet code available as a DLL?
No, it isn't. It would take a reasonable amount of rewriting for
this to be possible, and since the PuTTY project itself doesn't
believe in DLLs (they make installation more error-prone) none of us
has taken the time to do it.
Most of the code cleanup work would be a good thing to happen in
general, so if anyone feels like helping, we wouldn't say no.
See also
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/dll-frontend.html}{the wishlist entry}.
\S{faq-vb}{Question} Is the SSH or Telnet code available as a Visual
Basic component?
No, it isn't. None of the PuTTY team uses Visual Basic, and none of
us has any particular need to make SSH connections from a Visual
Basic application. In addition, all the preliminary work to turn it
into a DLL would be necessary first; and furthermore, we don't even
know how to write VB components.
If someone offers to do some of this work for us, we might consider
it, but unless that happens I can't see VB integration being
anywhere other than the very bottom of our priority list.
\S{faq-ipc}{Question} How can I use PuTTY to make an SSH connection
from within another program?
Probably your best bet is to use Plink, the command-line connection
tool. If you can start Plink as a second Windows process, and
arrange for your primary process to be able to send data to the
Plink process, and receive data from it, through pipes, then you
should be able to make SSH connections from your program.
This is what CVS for Windows does, for example.
\H{faq-details} Details of PuTTY's operation
\S{faq-term}{Question} What \i{terminal type} does PuTTY use?
For most purposes, PuTTY can be considered to be an \cw{xterm}
terminal.
PuTTY also supports some terminal \i{control sequences} not supported by
the real \cw{xterm}: notably the Linux console sequences that
reconfigure the colour palette, and the title bar control sequences
used by \i\cw{DECterm} (which are different from the \cw{xterm} ones;
PuTTY supports both).
By default, PuTTY announces its terminal type to the server as
\c{xterm}. If you have a problem with this, you can reconfigure it
to say something else; \c{vt220} might help if you have trouble.
\S{faq-settings}{Question} Where does PuTTY store its data?
On Windows, PuTTY stores most of its data (saved sessions, SSH host
keys) in the \i{Registry}. The precise location is
\c HKEY_CURRENT_USER\Software\SimonTatham\PuTTY
and within that area, saved sessions are stored under \c{Sessions}
while host keys are stored under \c{SshHostKeys}.
PuTTY also requires a random number seed file, to improve the
unpredictability of randomly chosen data needed as part of the SSH
cryptography. This is stored by default in a file called \i\c{PUTTY.RND};
this is stored by default in the \q{Application Data} directory,
or failing that, one of a number of fallback locations. If you
want to change the location of the random number seed file, you can
put your chosen pathname in the Registry, at
\c HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\RandSeedFile
You can ask PuTTY to delete all this data; see \k{faq-cleanup}.
On Unix, PuTTY stores all of this data in a directory \cw{~/.putty}.
\H{faq-howto} HOWTO questions
\S{faq-login}{Question} What login name / password should I use?
This is not a question you should be asking \e{us}.
PuTTY is a communications tool, for making connections to other
computers. We maintain the tool; we \e{don't} administer any computers
that you're likely to be able to use, in the same way that the people
who make web browsers aren't responsible for most of the content you can
view in them. \#{FIXME: less technical analogy?} We cannot help with
questions of this sort.
If you know the name of the computer you want to connect to, but don't
know what login name or password to use, you should talk to whoever
administers that computer. If you don't know who that is, see the next
question for some possible ways to find out.
\# FIXME: some people ask us to provide them with a login name
apparently as random members of the public rather than in the
belief that we run a server belonging to an organisation they already
have some relationship with. Not sure what to say to such people.
\S{faq-commands}{Question} \I{commands on the server}What commands
can I type into my PuTTY terminal window?
Again, this is not a question you should be asking \e{us}. You need
to read the manuals, or ask the administrator, of \e{the computer
you have connected to}.
PuTTY does not process the commands you type into it. It's only a
communications tool. It makes a connection to another computer; it
passes the commands you type to that other computer; and it passes
the other computer's responses back to you. Therefore, the precise
range of commands you can use will not depend on PuTTY, but on what
kind of computer you have connected to and what software is running
on it. The PuTTY team cannot help you with that.
(Think of PuTTY as being a bit like a telephone. If you phone
somebody up and you don't know what language to speak to make them
understand you, it isn't \e{the telephone company}'s job to find
that out for you. We just provide the means for you to get in touch;
making yourself understood is somebody else's problem.)
If you are unsure of where to start looking for the administrator of
your server, a good place to start might be to remember how you
found out the host name in the PuTTY configuration. If you were
given that host name by e-mail, for example, you could try asking
the person who sent you that e-mail. If your company's IT department
provided you with ready-made PuTTY saved sessions, then that IT
department can probably also tell you something about what commands
you can type during those sessions. But the PuTTY maintainer team
does not administer any server you are likely to be connecting to,
and cannot help you with questions of this type.
\S{faq-startmax}{Question} How can I make PuTTY start up \i{maximise}d?
Create a Windows shortcut to start PuTTY from, and set it as \q{Run
Maximized}.
\S{faq-startsess}{Question} How can I create a \i{Windows shortcut} to
start a particular saved session directly?
To run a PuTTY session saved under the name \q{\cw{mysession}},
create a Windows shortcut that invokes PuTTY with a command line
like
\c \path\name\to\putty.exe -load "mysession"
(Note: prior to 0.53, the syntax was \c{@session}. This is now
deprecated and may be removed at some point.)
\S{faq-startssh}{Question} How can I start an SSH session straight
from the command line?
Use the command line \c{putty -ssh host.name}. Alternatively, create
a saved session that specifies the SSH protocol, and start the saved
session as shown in \k{faq-startsess}.
\S{faq-cutpaste}{Question} How do I \i{copy and paste} between PuTTY and
other Windows applications?
Copy and paste works similarly to the X Window System. You use the
left mouse button to select text in the PuTTY window. The act of
selection \e{automatically} copies the text to the clipboard: there
is no need to press Ctrl-Ins or Ctrl-C or anything else. In fact,
pressing Ctrl-C will send a Ctrl-C character to the other end of
your connection (just like it does the rest of the time), which may
have unpleasant effects. The \e{only} thing you need to do, to copy
text to the clipboard, is to select it.
To paste the clipboard contents into a PuTTY window, by default you
click the right mouse button. If you have a three-button mouse and
are used to X applications, you can configure pasting to be done by
the middle button instead, but this is not the default because most
Windows users don't have a middle button at all.
You can also paste by pressing Shift-Ins.
\S{faq-options}{Question} How do I use all PuTTY's features (public
keys, proxying, cipher selection, etc.) in PSCP, PSFTP and Plink?
Most major features (e.g., public keys, port forwarding) are available
through command line options. See the documentation.
Not all features are accessible from the command line yet, although
we'd like to fix this. In the meantime, you can use most of
PuTTY's features if you create a PuTTY saved session, and then use
the name of the saved session on the command line in place of a
hostname. This works for PSCP, PSFTP and Plink (but don't expect
port forwarding in the file transfer applications!).
\S{faq-pscp}{Question} How do I use PSCP.EXE? When I double-click it
gives me a command prompt window which then closes instantly.
PSCP is a command-line application, not a GUI application. If you
run it without arguments, it will simply print a help message and
terminate.
To use PSCP properly, run it from a Command Prompt window. See
\k{pscp} in the documentation for more details.
\S{faq-pscp-spaces}{Question} \I{spaces in filenames}How do I use
PSCP to copy a file whose name has spaces in?
If PSCP is using the traditional SCP protocol, this is confusing. If
you're specifying a file at the local end, you just use one set of
quotes as you would normally do:
\c pscp "local filename with spaces" user@host:
\c pscp user@host:myfile "local filename with spaces"
But if the filename you're specifying is on the \e{remote} side, you
have to use backslashes and two sets of quotes:
\c pscp user@host:"\"remote filename with spaces\"" local_filename
\c pscp local_filename user@host:"\"remote filename with spaces\""
Worse still, in a remote-to-local copy you have to specify the local
file name explicitly, otherwise PSCP will complain that they don't
match (unless you specified the \c{-unsafe} option). The following
command will give an error message:
\c c:\>pscp user@host:"\"oo er\"" .
\c warning: remote host tried to write to a file called 'oo er'
\c when we requested a file called '"oo er"'.
Instead, you need to specify the local file name in full:
\c c:\>pscp user@host:"\"oo er\"" "oo er"
If PSCP is using the newer SFTP protocol, none of this is a problem,
and all filenames with spaces in are specified using a single pair
of quotes in the obvious way:
\c pscp "local file" user@host:
\c pscp user@host:"remote file" .
\H{faq-trouble} Troubleshooting
\S{faq-incorrect-mac}{Question} Why do I see \q{Incorrect MAC
received on packet}?
One possible cause of this that used to be common is a bug in old
SSH-2 servers distributed by \cw{ssh.com}. (This is not the only
possible cause; see \k{errors-crc} in the documentation.)
Version 2.3.0 and below of their SSH-2 server
constructs Message Authentication Codes in the wrong way, and
expects the client to construct them in the same wrong way. PuTTY
constructs the MACs correctly by default, and hence these old
servers will fail to work with it.
If you are using PuTTY version 0.52 or better, this should work
automatically: PuTTY should detect the buggy servers from their
version number announcement, and automatically start to construct
its MACs in the same incorrect manner as they do, so it will be able
to work with them.
If you are using PuTTY version 0.51 or below, you can enable the
workaround by going to the SSH panel and ticking the box labelled
\q{Imitate SSH2 MAC bug}. It's possible that you might have to do
this with 0.52 as well, if a buggy server exists that PuTTY doesn't
know about.
In this context MAC stands for \ii{Message Authentication Code}. It's a
cryptographic term, and it has nothing at all to do with Ethernet
MAC (Media Access Control) addresses.
\S{faq-pscp-protocol}{Question} Why do I see \q{Fatal: Protocol
error: Expected control record} in PSCP?
This happens because PSCP was expecting to see data from the server
that was part of the PSCP protocol exchange, and instead it saw data
that it couldn't make any sense of at all.
This almost always happens because the \i{startup scripts} in your
account on the server machine are generating output. This is
impossible for PSCP, or any other SCP client, to work around. You
should never use startup files (\c{.bashrc}, \c{.cshrc} and so on)
which generate output in non-interactive sessions.
This is not actually a PuTTY problem. If PSCP fails in this way,
then all other SCP clients are likely to fail in exactly the same
way. The problem is at the server end.
\S{faq-colours}{Question} I clicked on a colour in the \ii{Colours}
panel, and the colour didn't change in my terminal.
That isn't how you're supposed to use the Colours panel.
During the course of a session, PuTTY potentially uses \e{all} the
colours listed in the Colours panel. It's not a question of using
only one of them and you choosing which one; PuTTY will use them
\e{all}. The purpose of the Colours panel is to let you adjust the
appearance of all the colours. So to change the colour of the
cursor, for example, you would select \q{Cursor Colour}, press the
\q{Modify} button, and select a new colour from the dialog box that
appeared. Similarly, if you want your session to appear in green,
you should select \q{Default Foreground} and press \q{Modify}.
Clicking on \q{ANSI Green} won't turn your session green; it will
only allow you to adjust the \e{shade} of green used when PuTTY is
instructed by the server to display green text.
\S{faq-winsock2}{Question} Plink on \i{Windows 95} says it can't find
\i\cw{WS2_32.DLL}.
Plink requires the extended Windows network library, WinSock version
2. This is installed as standard on Windows 98 and above, and on
Windows NT, and even on later versions of Windows 95; but early
Win95 installations don't have it.
In order to use Plink on these systems, you will need to download
the
\W{http://www.microsoft.com/windows95/downloads/contents/wuadmintools/s_wunetworkingtools/w95sockets2/}{WinSock 2 upgrade}:
\c http://www.microsoft.com/windows95/downloads/contents/
\c wuadmintools/s_wunetworkingtools/w95sockets2/
\S{faq-outofmem}{Question} After trying to establish an SSH-2
connection, PuTTY says \q{\ii{Out of memory}} and dies.
If this happens just while the connection is starting up, this often
indicates that for some reason the client and server have failed to
establish a session encryption key. Somehow, they have performed
calculations that should have given each of them the same key, but
have ended up with different keys; so data encrypted by one and
decrypted by the other looks like random garbage.
This causes an \q{out of memory} error because the first encrypted
data PuTTY expects to see is the length of an SSH message. Normally
this will be something well under 100 bytes. If the decryption has
failed, PuTTY will see a completely random length in the region of
two \e{gigabytes}, and will try to allocate enough memory to store
this non-existent message. This will immediately lead to it thinking
it doesn't have enough memory, and panicking.
If this happens to you, it is quite likely to still be a PuTTY bug
and you should report it (although it might be a bug in your SSH
server instead); but it doesn't necessarily mean you've actually run
out of memory.
\S{faq-outofmem2}{Question} When attempting a file transfer, either
PSCP or PSFTP says \q{\ii{Out of memory}} and dies.
This is almost always caused by your \i{login scripts} on the server
generating output. PSCP or PSFTP will receive that output when they
were expecting to see the start of a file transfer protocol, and
they will attempt to interpret the output as file-transfer protocol.
This will usually lead to an \q{out of memory} error for much the
same reasons as given in \k{faq-outofmem}.
This is a setup problem in your account on your server, \e{not} a
PSCP/PSFTP bug. Your login scripts should \e{never} generate output
during non-interactive sessions; secure file transfer is not the
only form of remote access that will break if they do.
On Unix, a simple fix is to ensure that all the parts of your login
script that might generate output are in \c{.profile} (if you use a
Bourne shell derivative) or \c{.login} (if you use a C shell).
Putting them in more general files such as \c{.bashrc} or \c{.cshrc}
is liable to lead to problems.
\S{faq-psftp-slow}{Question} PSFTP transfers files much slower than PSCP.
The throughput of PSFTP 0.54 should be much better than 0.53b and
prior; we've added code to the SFTP backend to queue several blocks
of data rather than waiting for an acknowledgement for each. (The
SCP backend did not suffer from this performance issue because SCP
is a much simpler protocol.)
\S{faq-bce}{Question} When I run full-colour applications, I see
areas of black space where colour ought to be, or vice versa.
You almost certainly need to change the \q{Use \i{background colour} to
erase screen} setting in the Terminal panel. If there is too much
black space (the commoner situation), you should enable it, while if
there is too much colour, you should disable it. (See \k{config-erase}.)
In old versions of PuTTY, this was disabled by default, and would not
take effect until you reset the terminal (see \k{faq-resetterm}).
Since 0.54, it is enabled by default, and changes take effect
immediately.
\S{faq-resetterm}{Question} When I change some terminal settings,
nothing happens.
Some of the terminal options (notably \ii{Auto Wrap} and
background-colour screen erase) actually represent the \e{default}
setting, rather than the currently active setting. The server can
send sequences that modify these options in mid-session, but when
the terminal is reset (by server action, or by you choosing \q{Reset
Terminal} from the System menu) the defaults are restored.
In versions 0.53b and prior, if you change one of these options in
the middle of a session, you will find that the change does not
immediately take effect. It will only take effect once you reset
the terminal.
In version 0.54, the behaviour has changed - changes to these
settings take effect immediately.
\S{faq-idleout}{Question} My PuTTY sessions unexpectedly close after
they are \I{idle connections}idle for a while.
Some types of \i{firewall}, and almost any router doing Network Address
Translation (\i{NAT}, also known as IP masquerading), will forget about
a connection through them if the connection does nothing for too
long. This will cause the connection to be rudely cut off when
contact is resumed.
You can try to combat this by telling PuTTY to send \e{keepalives}:
packets of data which have no effect on the actual session, but
which reassure the router or firewall that the network connection is
still active and worth remembering about.
Keepalives don't solve everything, unfortunately; although they
cause greater robustness against this sort of router, they can also
cause a \e{loss} of robustness against network dropouts. See
\k{config-keepalive} in the documentation for more discussion of
this.
\S{faq-timeout}{Question} PuTTY's network connections time out too
quickly when \I{breaks in connectivity}network connectivity is
temporarily lost.
This is a Windows problem, not a PuTTY problem. The timeout value
can't be set on per application or per session basis. To increase
the TCP timeout globally, you need to tinker with the Registry.
On Windows 95, 98 or ME, the registry key you need to create or
change is
\c HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\
\c MSTCP\MaxDataRetries
(it must be of type DWORD in Win95, or String in Win98/ME).
(See MS Knowledge Base article
\W{http://support.microsoft.com/default.aspx?scid=kb;en-us;158474}{158474}
for more information.)
On Windows NT, 2000, or XP, the registry key to create or change is
\c HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
\c Parameters\TcpMaxDataRetransmissions
and it must be of type DWORD.
(See MS Knowledge Base articles
\W{http://support.microsoft.com/default.aspx?scid=kb;en-us;120642}{120642}
and
\W{http://support.microsoft.com/default.aspx?scid=kb;en-us;314053}{314053}
for more information.)
Set the key's value to something like 10. This will cause Windows to
try harder to keep connections alive instead of abandoning them.
\S{faq-puttyputty}{Question} When I \cw{cat} a binary file, I get
\q{PuTTYPuTTYPuTTY} on my command line.
Don't do that, then.
This is designed behaviour; when PuTTY receives the character
Control-E from the remote server, it interprets it as a request to
identify itself, and so it sends back the string \q{\cw{PuTTY}} as
if that string had been entered at the keyboard. Control-E should
only be sent by programs that are prepared to deal with the
response. Writing a binary file to your terminal is likely to output
many Control-E characters, and cause this behaviour. Don't do it.
It's a bad plan.
To mitigate the effects, you could configure the answerback string
to be empty (see \k{config-answerback}); but writing binary files to
your terminal is likely to cause various other unpleasant behaviour,
so this is only a small remedy.
\S{faq-wintitle}{Question} When I \cw{cat} a binary file, my \i{window
title} changes to a nonsense string.
Don't do that, then.
It is designed behaviour that PuTTY should have the ability to
adjust the window title on instructions from the server. Normally
the control sequence that does this should only be sent
deliberately, by programs that know what they are doing and intend
to put meaningful text in the window title. Writing a binary file to
your terminal runs the risk of sending the same control sequence by
accident, and cause unexpected changes in the window title. Don't do
it.
\S{faq-password-fails}{Question} My \i{keyboard} stops working once
PuTTY displays the \i{password prompt}.
No, it doesn't. PuTTY just doesn't display the password you type, so
that someone looking at your screen can't see what it is.
Unlike the Windows login prompts, PuTTY doesn't display the password
as a row of asterisks either. This is so that someone looking at
your screen can't even tell how \e{long} your password is, which
might be valuable information.
\S{faq-keyboard}{Question} One or more \I{keyboard}\i{function keys}
don't do what I expected in a server-side application.
If you've already tried all the relevant options in the PuTTY
Keyboard panel, you may need to mail the PuTTY maintainers and ask.
It is \e{not} usually helpful just to tell us which application,
which server operating system, and which key isn't working; in order
to replicate the problem we would need to have a copy of every
operating system, and every application, that anyone has ever
complained about.
PuTTY responds to function key presses by sending a sequence of
control characters to the server. If a function key isn't doing what
you expect, it's likely that the character sequence your application
is expecting to receive is not the same as the one PuTTY is sending.
Therefore what we really need to know is \e{what} sequence the
application is expecting.
The simplest way to investigate this is to find some other terminal
environment, in which that function key \e{does} work; and then
investigate what sequence the function key is sending in that
situation. One reasonably easy way to do this on a \i{Unix} system is to
type the command \i\c{cat}, and then press the function key. This is
likely to produce output of the form \c{^[[11~}. You can also do
this in PuTTY, to find out what sequence the function key is
producing in that. Then you can mail the PuTTY maintainers and tell
us \q{I wanted the F1 key to send \c{^[[11~}, but instead it's
sending \c{^[OP}, can this be done?}, or something similar.
You should still read the
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/feedback.html}{Feedback
page} on the PuTTY website (also provided as \k{feedback} in the
manual), and follow the guidelines contained in that.
\S{faq-openssh-bad-openssl}{Question} Since my SSH server was upgraded
to \i{OpenSSH} 3.1p1/3.4p1, I can no longer connect with PuTTY.
There is a known problem when OpenSSH has been built against an
incorrect version of OpenSSL; the quick workaround is to configure
PuTTY to use SSH protocol 2 and the Blowfish cipher.
For more details and OpenSSH patches, see
\W{http://bugzilla.mindrot.org/show_bug.cgi?id=138}{bug 138} in the
OpenSSH BTS.
This is not a PuTTY-specific problem; if you try to connect with
another client you'll likely have similar problems. (Although PuTTY's
default cipher differs from many other clients.)
\e{OpenSSH 3.1p1:} configurations known to be broken (and symptoms):
\b SSH-2 with AES cipher (PuTTY says \q{Assertion failed! Expression:
(len & 15) == 0} in \cw{sshaes.c}, or \q{Out of memory}, or crashes)
\b SSH-2 with 3DES (PuTTY says \q{Incorrect MAC received on packet})
\b SSH-1 with Blowfish (PuTTY says \q{Incorrect CRC received on
packet})
\b SSH-1 with 3DES
\e{OpenSSH 3.4p1:} as of 3.4p1, only the problem with SSH-1 and
Blowfish remains. Rebuild your server, apply the patch linked to from
bug 138 above, or use another cipher (e.g., 3DES) instead.
\e{Other versions:} we occasionally get reports of the same symptom
and workarounds with older versions of OpenSSH, although it's not
clear the underlying cause is the same.
\S{faq-ssh2key-ssh1conn}{Question} Why do I see \q{Couldn't load
private key from ...}? Why can PuTTYgen load my key but not PuTTY?
It's likely that you've generated an SSH protocol 2 key with PuTTYgen,
but you're trying to use it in an SSH-1 connection. SSH-1 and SSH-2 keys
have different formats, and (at least in 0.52) PuTTY's reporting of a
key in the wrong format isn't optimal.
To connect using SSH-2 to a server that supports both versions, you
need to change the configuration from the default (see \k{faq-ssh2}).
\S{faq-rh8-utf8}{Question} When I'm connected to a \i{Red Hat Linux} 8.0
system, some characters don't display properly.
A common complaint is that hyphens in man pages show up as a-acute.
With release 8.0, Red Hat appear to have made \i{UTF-8} the default
character set. There appears to be no way for terminal emulators such
as PuTTY to know this (as far as we know, the appropriate escape
sequence to switch into UTF-8 mode isn't sent).
A fix is to configure sessions to RH8 systems to use UTF-8
translation - see \k{config-charset} in the documentation. (Note that
if you use \q{Change Settings}, changes may not take place immediately
- see \k{faq-resetterm}.)
If you really want to change the character set used by the server, the
right place is \c{/etc/sysconfig/i18n}, but this shouldn't be
necessary.
\S{faq-screen}{Question} Since I upgraded to PuTTY 0.54, the
scrollback has stopped working when I run \c{screen}.
PuTTY's terminal emulator has always had the policy that when the
\q{\i{alternate screen}} is in use, nothing is added to the scrollback.
This is because the usual sorts of programs which use the alternate
screen are things like text editors, which tend to scroll back and
forth in the same document a lot; so (a) they would fill up the
scrollback with a large amount of unhelpfully disordered text, and
(b) they contain their \e{own} method for the user to scroll back to
the bit they were interested in. We have generally found this policy
to do the Right Thing in almost all situations.
Unfortunately, \c{screen} is one exception: it uses the alternate
screen, but it's still usually helpful to have PuTTY's scrollback
continue working. The simplest solution is to go to the Features
control panel and tick \q{Disable switching to alternate terminal
screen}. (See \k{config-features-altscreen} for more details.)
Alternatively, you can tell \c{screen} itself not to use the
alternate screen: the
\W{http://www4.informatik.uni-erlangen.de/~jnweiger/screen-faq.html}{\c{screen}
FAQ} suggests adding the line \cq{termcapinfo xterm ti@:te@} to your
\cw{.screenrc} file.
The reason why this only started to be a problem in 0.54 is because
\c{screen} typically uses an unusual control sequence to switch to
the alternate screen, and previous versions of PuTTY did not support
this sequence.
\S{faq-alternate-localhost}{Question} Since I upgraded \i{Windows XP}
to Service Pack 2, I can't use addresses like \cw{127.0.0.2}.
Some people who ask PuTTY to listen on \i{localhost} addresses other
than \cw{127.0.0.1} to forward services such as \i{SMB} and \i{Windows
Terminal Services} have found that doing so no longer works since
they upgraded to WinXP SP2.
This is apparently an issue with SP2 that is acknowledged by Microsoft
in MS Knowledge Base article
\W{http://support.microsoft.com/default.aspx?scid=kb;en-us;884020}{884020}.
The article links to a fix you can download.
(\e{However}, we've been told that SP2 \e{also} fixes the bug that
means you need to use non-\cw{127.0.0.1} addresses to forward
Terminal Services in the first place.)
\S{faq-missing-slash}{Question} PSFTP commands seem to be missing a
directory separator (slash).
Some people have reported the following incorrect behaviour with
PSFTP:
\c psftp> pwd
\e iii
\c Remote directory is /dir1/dir2
\c psftp> get filename.ext