Previous | Contents | Index | Next
ssh.com SSHv2 private key files?WS2_32.DLL.cat a binary file, I get `PuTTYPuTTYPuTTY' on my command line.cat a binary file, my window title changes to a nonsense string.screen.127.0.0.2.VirtualLock() to stop private keys being written to disk?This FAQ is published on the PuTTY web site, and also provided as an appendix in the manual.
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.
In general, if you want to know if PuTTY supports a particular feature, you should look for it on the PuTTY web site. In particular:
Yes. SSH v2 support has been available in PuTTY since version 0.50.
Public key authentication (both RSA and DSA) in SSH v2 is new in version 0.52.
ssh.com SSHv2 private key files?
PuTTY doesn't support this natively, but as of 0.53 PuTTYgen can convert both OpenSSH and ssh.com private key files into PuTTY's format.
Yes. SSH 1 support has always been available in PuTTY.
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 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 ˙Line discipline options˙.
Yes, all of PuTTY's settings can be saved in named session profiles. See section 4.1.2 in the documentation for how to do this.
Not at present, although section 4.21 in the documentation gives a method of achieving the same effect.
Yes; this is a new feature in version 0.52.
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 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 ˙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 chapter 8 in the documentation for a full discussion of public key authentication.
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 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 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 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 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. That way, you retain the 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 known_hosts format, we have a script called kh2reg.py to convert them to a Windows .REG file, which can be installed ahead of time by double-clicking or using REGEDIT.
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.
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.
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.
Currently, release versions of PuTTY tools only run on full Win32 systems and Unix. ˙Win32˙ includes Windows 95, 98, and ME, and it includes Windows NT, Windows 2000 and Windows XP.
In the development code, a partial port to the Mac OS (see question A.3.6) is under way.
Currently PuTTY does not run on Windows CE (see question A.3.4), and it does not quite run on the Win32s environment under Windows 3.1 (see question A.3.5).
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 Links page of our website.
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 unix subdirectory containing Makefile.gtk, which should build you Unix ports of Plink, PuTTY itself, PuTTYgen, PSCP, PSFTP, and also pterm - an 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 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.
All sorts of little things. pterm is directly useful to anyone who prefers PuTTY's terminal emulation to 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 Valgrind to help with debugging, which has already improved PuTTY's stability on 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.
It's currently being worked on, but it's only in its early stages yet, and certainly isn't yet useful. PuTTY on portable devices would clearly be a useful thing, so in the long term I hope it can be brought up to release quality.
There's also a third-party port at http://pocketputty.duxy.net/.
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 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 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!
There is a port to the Mac OS in progress. It's just about usable, but has an awful lot of gaps and rough edges that will need cleaning up before release (such as useful random numbers).
A separate port to Mac OS X is also underway.
I hope so, but given that ports aren't really progressing very fast even on systems the developers 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, and a beta port of PuTTY for the Nokia 9200 Communicator series is available from http://s2putty.sourceforge.net/
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.
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.
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.
For most purposes, PuTTY can be considered to be an xterm terminal.
PuTTY also supports some terminal control sequences not supported by the real xterm: notably the Linux console sequences that reconfigure the colour palette, and the title bar control sequences used by DECterm (which are different from the xterm ones; PuTTY supports both).
By default, PuTTY announces its terminal type to the server as xterm. If you have a problem with this, you can reconfigure it to say something else; vt220 might help if you have trouble.
On Windows, PuTTY stores most of its data (saved sessions, SSH host keys) in the Registry. The precise location is
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY
and within that area, saved sessions are stored under Sessions while host keys are stored under 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 your Windows home directory (%HOMEDRIVE%\%HOMEPATH%), or in the actual Windows directory (such as C:\WINDOWS) if the home directory doesn't exist, for example if you're using Win95. If you want to change the location of the random number seed file, you can put your chosen pathname in the Registry, at
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\RandSeedFile
On Unix, PuTTY stores all of this data in a directory ~/.putty.
Create a Windows shortcut to start PuTTY from, and set it as ˙Run Maximized˙.
To run a PuTTY session saved under the name ˙mysession˙, create a Windows shortcut that invokes PuTTY with a command line like
\path\name\to\putty.exe -load mysession
(Note: prior to 0.53, the syntax was @session. This is now deprecated and may be removed at some point.)
Use the command line putty -ssh host.name. Alternatively, create a saved session that specifies the SSH protocol, and start the saved session as shown in question A.6.2.
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 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 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.
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!).
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 chapter 5 in the documentation for more details.
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:
pscp "local filename with spaces" user@host:
pscp user@host:myfile "local filename with spaces"
But if the filename you're specifying is on the remote side, you have to use backslashes and two sets of quotes:
pscp user@host:"\"remote filename with spaces\"" local_filename
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 -unsafe option). The following command will give an error message:
c:\>pscp user@host:"\"oo er\"" .
warning: remote host tried to write to a file called 'oo er'
when we requested a file called '"oo er"'.
Instead, you need to specify the local file name in full:
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:
pscp "local file" user@host:
pscp user@host:"remote file" .
One possible cause of this that used to be common is a bug in old SSH 2 servers distributed by ssh.com. (This is not the only possible cause; see section 10.11 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 ˙Imitate SSH 2 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 Message Authentication Code. It's a cryptographic term, and it has nothing at all to do with Ethernet MAC (Media Access Control) addresses.
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 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 (.bashrc, .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.
That isn't how you're supposed to use the Colours panel.
During the course of a session, PuTTY potentially uses 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 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 ˙Cursor Colour˙, press the ˙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 ˙Default Foreground˙ and press ˙Modify˙. Clicking on ˙ANSI Green˙ won't turn your session green; it will only allow you to adjust the shade of green used when PuTTY is instructed by the server to display green text.
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 WinSock 2 upgrade:
http://www.microsoft.com/windows95/downloads/contents/
wuadmintools/s_wunetworkingtools/w95sockets2/
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 ˙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 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.
This is almost always caused by your 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 ˙out of memory˙ error for much the same reasons as given in question A.7.5.
This is a setup problem in your account on your server, not a PSCP/PSFTP bug. Your login scripts should 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 .profile (if you use a Bourne shell derivative) or .login (if you use a C shell). Putting them in more general files such as .bashrc or .cshrc is liable to lead to problems.
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.)
You almost certainly need to enable the ˙Use background colour to erase screen˙ setting in the Terminal panel. Note that if you do this in mid-session, in versions before 0.54, it may not take effect until you reset the terminal (see question A.7.9).
Some of the terminal options (notably Auto Wrap and background-colour screen erase) actually represent the 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 ˙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.
Some types of firewall, and almost any router doing Network Address Translation (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 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 loss of robustness against network dropouts. See section 4.13.5 in the documentation for more discussion of this.
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
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\
MSTCP\MaxDataRetries
(it must be of type DWORD in Win95, or String in Win98/ME). (See MS Knowledge Base article 158474 for more information.)
On Windows NT or 2000, the registry key is
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
Parameters\TcpMaxDataRetransmissions
and it must be of type DWORD. (See MS Knowledge Base article 120642 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.
cat a binary file, I get `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 ˙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 section 4.3.6); but writing binary files to your terminal is likely to cause various other unpleasant behaviour, so this is only a small remedy.
cat a binary file, my 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.
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 long your password is, which might be valuable information.
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 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 what sequence the application is expecting.
The simplest way to investigate this is to find some other terminal environment, in which that function key does work; and then investigate what sequence the function key is sending in that situation. One reasonably easy way to do this on a Unix system is to type the command cat, and then press the function key. This is likely to produce output of the form ^[[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 ˙I wanted the F1 key to send ^[[11~, but instead it's sending ^[OP, can this be done?˙, or something similar.
You should still read the Feedback page on the PuTTY website (also provided as appendix B in the manual), and follow the guidelines contained in that.
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 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.)
OpenSSH 3.1p1: configurations known to be broken (and symptoms):
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.
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.
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. SSH1 and SSH2 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 question A.2.1).
A common complaint is that hyphens in man pages show up as a-acute.
With release 8.0, Red Hat appear to have made 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 section 4.10.1 in the documentation. (Note that if you use ˙Change Settings˙, changes may not take place immediately - see question A.7.9.)
If you really want to change the character set used by the server, the right place is /etc/sysconfig/i18n, but this shouldn't be necessary.
screen.PuTTY's terminal emulator has always had the policy that when the ˙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 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, 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 ˙Disable switching to alternate terminal screen˙. (See section 4.6.4 for more details.)
The reason why this only started to be a problem in 0.54 is because screen typically uses an unusual control sequence to switch to the alternate screen, and previous versions of PuTTY did not support this sequence.
127.0.0.2.
Some people who ask PuTTY to listen on localhost addresses other than 127.0.0.1 to forward services such as SMB and 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 884020. The article links to a fix you can download.
(However, we've been told that SP2 also fixes the bug that means you need to use non-127.0.0.1 addresses to forward Terminal Services in the first place.)
Some people have reported the following incorrect behaviour with PSFTP:
psftp> pwd
Remote directory is /dir1/dir2
psftp> get filename.ext
/dir1/dir2filename.ext: no such file or directory
This is not a bug in PSFTP. There is a known bug in some versions of portable OpenSSH (bug 697) that causes these symptoms; it appears to have been introduced around 3.7.x. It manifests only on certain platforms (AIX is what has been reported to us).
There is a patch for OpenSSH attached to that bug; it's also fixed in recent versions of portable OpenSSH (from around 3.8).
It depends on whether you trust that PC. If you don't trust the public PC, don't use PuTTY on it, and don't use any other software you plan to type passwords into either. It might be watching your keystrokes, or it might tamper with the PuTTY binary you download. There is no program safe enough that you can run it on an actively malicious PC and get away with typing passwords into it.
If you do trust the PC, then it's probably OK to use PuTTY on it (but if you don't trust the network, then the PuTTY download might be tampered with, so it would be better to carry PuTTY with you on a floppy).
PuTTY will leave some Registry entries, and a random seed file, on the PC (see question A.5.2). If you are using PuTTY on a public PC, or somebody else's PC, you might want to clean these up when you leave. You can do that automatically, by running the command putty -cleanup.
DSA has a major weakness if badly implemented: it relies on a random number generator to far too great an extent. If the random number generator produces a number an attacker can predict, the DSA private key is exposed - meaning that the attacker can log in as you on all systems that accept that key.
The PuTTY policy changed because the developers were informed of ways to implement DSA which do not suffer nearly as badly from this weakness, and indeed which don't need to rely on random numbers at all. For this reason we now believe PuTTY's DSA implementation is probably OK. However, if you have the choice, we still recommend you use RSA instead.
VirtualLock() to stop private keys being written to disk?
Unfortunately not. The VirtualLock() function in the Windows API doesn't do a proper job: it may prevent small pieces of a process's memory from being paged to disk while the process is running, but it doesn't stop the process's memory as a whole from being swapped completely out to disk when the process is long-term inactive. And Pageant spends most of its time inactive.
No, thank you. Even if you can find one (most of them seem to have been registered already, by people who didn't ask whether we actually wanted it before they applied), we're happy with the PuTTY web site being exactly where it is. It's not hard to find (just type ˙putty˙ into google.com and we're the first link returned), and we don't believe the administrative hassle of moving the site would be worth the benefit.
In addition, if we did want a custom domain name, we would want to run it ourselves, so we knew for certain that it would continue to point where we wanted it, and wouldn't suddenly change or do strange things. Having it registered for us by a third party who we don't even know is not the best way to achieve this.
We already have some, thanks.
Only if the content of your web page is of definite direct interest to PuTTY users. If your content is unrelated, or only tangentially related, to PuTTY, then the link would simply be advertising for you.
One very nice effect of the Google ranking mechanism is that by and large, the most popular web sites get the highest rankings. This means that when an ordinary person does a search, the top item in the search is very likely to be a high-quality site or the site they actually wanted, rather than the site which paid the most money for its ranking.
The PuTTY web site is held in high esteem by Google, for precisely this reason: lots of people have linked to it simply because they like PuTTY, without us ever having to ask anyone to link to us. We feel that it would be an abuse of this esteem to use it to boost the ranking of random advertisers' web sites. If you want your web site to have a high Google ranking, we'd prefer that you achieve this the way we did - by being good enough at what you do that people will link to you simply because they like you.
In particular, we aren't interested in trading links for money (see above), and we certainly aren't interested in trading links for other links (since we have no advertising on our web site, our Google ranking is not even directly worth anything to us). If we don't want to link to you for free, then we probably won't want to link to you at all.
If you have software based on PuTTY, or specifically designed to interoperate with PuTTY, or in some other way of genuine interest to PuTTY users, then we will probably be happy to add a link to you on our Links page. And if you're running a mirror of the PuTTY web site, we're definitely interested.
Partly, because we don't want to move the web site location (see question A.9.1).
Also, security reasons. PuTTY is a security product, and as such it is particularly important to guard the code and the web site against unauthorised modifications which might introduce subtle security flaws. Therefore, we prefer that the CVS repository, web site and FTP site remain where they are, under the direct control of system administrators we know and trust personally, rather than being run by a large organisation full of people we've never met and which is known to have had breakins in the past.
No offence to SourceForge; I think they do a wonderful job. But they're not ideal for everyone, and in particular they're not ideal for us.
Because you're not a member of the PuTTY core development team. The putty-bugs mailing list is not a general newsgroup-like discussion forum; it's a contact address for the core developers, and an internal mailing list for us to discuss things among ourselves. If we opened it up for everybody to subscribe to, it would turn into something more like a newsgroup and we would be completely overwhelmed by the volume of traffic. It's hard enough to keep up with the list as it is.
There isn't one, that we know of.
If someone else wants to set up a mailing list or other forum for PuTTY users to help each other with common problems, that would be fine with us, though the PuTTY team would almost certainly not have the time to read it. It's probably better to use the established newsgroup comp.security.ssh for this purpose.
Please, please don't feel you have to. PuTTY is completely free software, and not shareware. We think it's very important that everybody who wants to use PuTTY should be able to, whether they have any money or not; so the last thing we would want is for a PuTTY user to feel guilty because they haven't paid us any money. If you want to keep your money, please do keep it. We wouldn't dream of asking for any.
Having said all that, if you still really want to give us money, we won't argue :-) The easiest way for us to accept donations is if you send money to <anakin@pobox.com> using PayPal (www.paypal.com). Alternatively, if you don't trust PayPal, you could donate through e-gold (www.e-gold.com): deposit your donation in account number 174769, then send us e-mail to let us know you've done so (otherwise we might not notice for months!).
Small donations (tens of dollars or tens of euros) will probably be spent on beer or curry, which helps motivate our volunteer team to continue doing this for the world. Larger donations will be spent on something that actually helps development, if we can find anything (perhaps new hardware, or a copy of Windows XP), but if we can't find anything then we'll just distribute the money among the developers. If you want to be sure your donation is going towards something worthwhile, ask us first. If you don't like these terms, feel perfectly free not to donate. We don't mind.
Yes. You need not bother asking us explicitly for permission. You already have permission. Redistribution of the unmodified PuTTY binary in this way is entirely permitted by our licence (see appendix C), and you are welcome to do it as much as you like.
If you are distributing PuTTY within your own organisation, or for use with your own product, then we recommend (but do not insist) that you offer your own first-line technical support, to answer questions directly relating to the interaction of PuTTY with your particular environment. If your users mail us directly, we won't be able to give them very much help about things specific to your own setup.
No, it isn't. PuTTY is almost completely composed of code written from scratch for PuTTY. The only code we share with OpenSSH is the detector for SSH1 CRC compensation attacks, written by CORE SDI S.A.
You're looking at the wrong web site; the only PuTTY we know about here is the name of a computer program.
If you want the kind of putty you can buy as an executive toy, the PuTTY team can personally recommend Thinking Putty, which you can buy from Crazy Aaron's Putty World, at www.puttyworld.com.
It's the name of a popular SSH and Telnet client. Any other meaning is in the eye of the beholder. It's been rumoured that ˙PuTTY˙ is the antonym of ˙getty˙, or that it's the stuff that makes your Windows useful, or that it's a kind of plutonium Teletype. We couldn't possibly comment on such allegations.
Exactly like the English word ˙putty˙, which we pronounce /˙p˙t˙/.
If you want to provide feedback on this manual or on the PuTTY tools themselves, see the Feedback page.
[$Id: blurb.but,v 1.11.2.2 2004/10/24 22:58:17 jacob Exp $]