Copyright: This manual is copyright 2001 Simon Tatham. All rights reserved. You may distribute this documentation under the MIT licence. See appendix C for the licence text in full.


Contents
PuTTY User Manual

PuTTY is a free (MIT-licensed) Win32 Telnet and SSH client. This manual documents PuTTY, and its companion utilities PSCP, Plink, Pageant and PuTTYgen.

This manual is copyright 2001 Simon Tatham. All rights reserved. You may distribute this documentation under the MIT licence. See appendix C for the licence text in full.

Chapter 1: Introduction to PuTTY

Chapter 2: Getting started with PuTTY

Chapter 3: Using PuTTY

Chapter 4: Configuring PuTTY

Chapter 5: Using PSCP to transfer files securely

Chapter 6: Using PSFTP to transfer files securely

Chapter 7: Using the command-line connection tool Plink

Chapter 8: Using public keys for SSH authentication

Chapter 9: Using Pageant for authentication

Appendix A: PuTTY FAQ

Appendix B: Feedback and bug reporting

Appendix C: PuTTY Licence


Chapter 1: Introduction to PuTTY

PuTTY is a free SSH, Telnet and Rlogin client for 32-bit Windows systems.

Section 1.1: What are SSH, Telnet and Rlogin?

Section 1.2: How do SSH, Telnet and Rlogin differ?


Section 1.1: What are SSH, Telnet and Rlogin?

If you already know what SSH, Telnet and Rlogin are, you can safely skip on to the next section.

SSH, Telnet and Rlogin are three ways of doing the same thing: logging in to a multi-user computer from another computer, over a network.

Multi-user operating systems, such as Unix and VMS, usually present a command-line interface to the user, much like the ‘Command Prompt’ or ‘MS-DOS Prompt’ in Windows. The system prints a prompt, and you type commands which the system will obey.

Using this type of interface, there is no need for you to be sitting at the same machine you are typing commands to. The commands, and responses, can be sent over a network, so you can sit at one computer and give commands to another one, or even to more than one.

SSH, Telnet and Rlogin are network protocols that allow you to do this. On the computer you sit at, you run a client, which makes a network connection to the other computer (the server). The network connection carries your keystrokes and commands from the client to the server, and carries the server's responses back to you.

These protocols can also be used for other types of keyboard-based interactive session. In particular, there are a lot of bulletin boards, talker systems and MUDs (Multi-User Dungeons) which support access using Telnet. There are even a few that support SSH.

You might want to use SSH, Telnet or Rlogin if:

•	you have an account on a Unix or VMS system which you want to be able to access from somewhere else

•	your Internet Service Provider provides you with a login account on a web server. (This might also be known as a shell account. A shell is the program that runs on the server and interprets your commands for you.)

•	you want to use a bulletin board system, talker or MUD which can be accessed using Telnet.

You probably do not want to use SSH, Telnet or Rlogin if:

•	you only use Windows. Windows computers have their own ways of networking between themselves, and unless you are doing something fairly unusual, you will not need to use any of these remote login protocols.


Section 1.2: How do SSH, Telnet and Rlogin differ?

This list summarises some of the differences between SSH, Telnet and Rlogin.

•	SSH is a recently designed, high-security protocol. It uses strong cryptography to protect your connection against eavesdropping, hijacking and other attacks. Telnet and Rlogin are both older protocols offering minimal security.

•	Telnet allows you to pass some settings on to the server, such as environment variables. (These control various aspects of the server's behaviour. You can usually set them by entering commands into the server once you're connected, but it's easier to have Telnet do it automatically.) SSH and Rlogin do not support this. However, most modern Telnet servers don't allow it either, because it has been a constant source of security problems.

•	SSH and Rlogin both allow you to log in to the server without having to type a password. (Rlogin's method of doing this is insecure, and can allow an attacker to access your account on the server. SSH's method is much more secure, and typically breaking the security requires the attacker to have gained access to your actual client machine.)

•	SSH allows you to connect to the server and automatically send a command, so that the server will run that command and then disconnect. So you can use it in automated processing.

The Internet is a hostile environment and security is everybody's responsibility. If you are connecting across the open Internet, then we recommend you use SSH. If the server you want to connect to doesn't support SSH, it might be worth trying to persuade the administrator to install it.

If you are behind a good firewall, it is more likely to be safe to use Telnet or Rlogin, but we still recommend you use SSH.


Chapter 2: Getting started with PuTTY

This chapter gives a quick guide to the simplest types of interactive login session using PuTTY.

Section 2.1: Starting a session

Section 2.2: Verifying the Host Key (SSH only)

Section 2.3: Logging In

Section 2.4: After Logging In

Section 2.5: Logging Out


Section 2.1: Starting a session

When you start PuTTY, you will see a dialog box. This dialog box allows you to control everything PuTTY can do. See chapter 4 for details of all the things you can control.

You don't usually need to change most of the configuration options. To start the simplest kind of session, all you need to do is to enter a few basic parameters.

In the ‘Host Name’ box, enter the Internet host name of the server you want to connect to. You should have been told this by the provider of your login account.

Now select a login protocol to use, from the ‘Protocol’ buttons. For a login session, you should select Telnet, Rlogin or SSH. See section 1.2 for a description of the differences between the three protocols, and advice on which one to use. The fourth protocol, Raw, is not used for interactive login sessions; you would usually use this for debugging other Internet services.

When you change the selected protocol, the number in the ‘Port’ box will change. This is normal: it happens because the various login services are usually provided on different network ports by the server machine. Most servers will use the standard port numbers, so you will not need to change the port setting. If your server provides login services on a non-standard port, your system administrator should have told you which one. (For example, many MUDs run Telnet service on a port other than 23.)

Once you have filled in the ‘Host Name’, ‘Protocol’, and possibly ‘Port’ settings, you are ready to connect. Press the ‘Open’ button at the bottom of the dialog box, and PuTTY will begin trying to connect you to the server.


Section 2.2: Verifying the Host Key (SSH only)

If you are not using the SSH protocol, you can skip this section.

If you are using SSH to connect to a server for the first time, you will probably see a message looking something like this:

The server's host key is not cached in the registry. You

have no guarantee that the server is the computer you

think it is.

The server's key fingerprint is:

ssh-rsa 1024 7b:e5:6f:a7:f4:f9:81:62:5c:e3:1f:bf:8b:57:6c:5a

If you trust this host, hit Yes to add the key to

PuTTY's cache and carry on connecting.

If you want to carry on connecting just once, without

adding the key to the cache, hit No.

If you do not trust this host, hit Cancel to abandon the

connection.

This is a feature of the SSH protocol. It is designed to protect you against a network attack known as spoofing: secretly redirecting your connection to a different computer, so that you send your password to the wrong machine. Using this technique, an attacker would be able to learn the password that guards your login account, and could then log in as if they were you and use the account for their own purposes.

To prevent this attack, each server has a unique identifying code, called a host key. These keys are created in a way that prevents one server from forging another server's key. So if you connect to a server and it sends you a different host key from the one you were expecting, PuTTY can warn you that the server may have been switched and that a spoofing attack might be in progress.

PuTTY records the host key for each server you connect to, in the Windows Registry. Every time you connect to a server, it checks that the host key presented by the server is the same host key as it was the last time you connected. If it is not, you will see a warning, and you will have the chance to abandon your connection before you type any private information (such as a password) into it.

However, when you connect to a server you have not connected to before, PuTTY has no way of telling whether the host key is the right one or not. So it gives the warning shown above, and asks you whether you want to trust this host key or not.

Whether or not to trust the host key is your choice. If you are connecting within a company network, you might feel that all the network users are on the same side and spoofing attacks are unlikely, so you might choose to trust the key without checking it. If you are connecting across a hostile network (such as the Internet), you should check with your system administrator, perhaps by telephone or in person. (Some modern servers have more than one host key. If the system administrator sends you more than one fingerprint, you should make sure the one PuTTY shows you is on the list, but it doesn't matter which one it is.)


Section 2.3: Logging In

After you have connected, and perhaps verified the server's host key, you will be asked to log in, probably using a username and a password. Your system administrator should have provided you with these. Enter the username and the password, and the server should grant you access and begin your session. If you have mistyped your password, most servers will give you several chances to get it right.

If you are using SSH, be careful not to type your username wrongly, because you will not have a chance to correct it after you press Return. This is an unfortunate feature of the SSH protocol: it does not allow you to make two login attempts using different usernames. If you type your username wrongly, you must close PuTTY and start again.

If your password is refused but you are sure you have typed it correctly, check that Caps Lock is not enabled. Many login servers, particularly Unix computers, treat upper case and lower case as different when checking your password; so if Caps Lock is on, your password will probably be refused.


Section 2.4: After Logging In

After you log in to the server, what happens next is up to the server! Most servers will print some sort of login message and then present a prompt, at which you can type commands which the server will carry out. Some servers will offer you on-line help; others might not. If you are in doubt about what to do next, consult your system administrator.


Section 2.5: Logging Out

When you have finished your session, you should log out by typing the server's own logout command. This might vary between servers; if in doubt, try logout or exit, or consult a manual or your system administrator. When the server processes your logout command, the PuTTY window should close itself automatically.

You can close a PuTTY session using the Close button in the window border, but this might confuse the server - a bit like hanging up a telephone unexpectedly in the middle of a conversation. We recommend you do not do this unless the server has stopped responding to you and you cannot close the window any other way.


Chapter 3: Using PuTTY

This chapter provides a general introduction to some more advanced features of PuTTY. For extreme detail and reference purposes, chapter 4 is likely to contain more information.

Section 3.1: During your session

Section 3.2: Creating a log file of your session

Section 3.3: Altering your character set configuration

Section 3.4: Using X11 forwarding in SSH

Section 3.5: Using port forwarding in SSH

Section 3.6: Making raw TCP connections


Section 3.1: During your session

A lot of PuTTY's complexity and features are in the configuration panel. Once you have worked your way through that and started a session, things should be reasonably simple after that. Nevertheless, there are a few more useful features available.

Section 3.1.1: Copying and pasting text

Section 3.1.2: Scrolling the screen back

Section 3.1.3: The System menu


Section 3.1.1: Copying and pasting text

Often in a PuTTY session you will find text on your terminal screen which you want to type in again. Like most other terminal emulators, PuTTY allows you to copy and paste the text rather than having to type it again. Also, copy and paste uses the Windows clipboard, so that you can paste (for example) URLs into a web browser, or paste from a word processor or spreadsheet into your terminal session.

PuTTY's copy and paste works entirely with the mouse. In order to copy text to the clipboard, you just click the left mouse button in the terminal window, and drag to select text. When you let go of the button, the text is automatically copied to the clipboard. You do not need to press Ctrl-C or Ctrl-Ins; in fact, if you do press Ctrl-C, PuTTY will send a Ctrl-C character down your session to the server where it will probably cause a process to be interrupted.

Pasting is done using the right button (or the middle mouse button, if you have a three-button mouse and have set it up; see section 4.10.3). When you click the right mouse button, PuTTY will read whatever is in the Windows Clipboard and paste it into your session, exactly as if it had been typed at the keyboard. (Therefore, be careful of pasting formatted text into an editor that does automatic indenting; you may find that the spaces pasted from the clipboard plus the spaces added by the editor add up to too many spaces and ruin the formatting. There is nothing PuTTY can do about this.)

If you double-click the left mouse button, PuTTY will select a whole word. If you double-click, hold down the second click, and drag the mouse, PuTTY will select a sequence of whole words. (You can adjust precisely what PuTTY considers to be part of a word; see section 4.10.6.) If you triple-click, or triple-click and drag, then PuTTY will select a whole line or sequence of lines.

If you want to select a rectangular region instead of selecting to the end of each line, you can do this by holding down Alt when you make your selection. (You can also configure rectangular selection to be the default, and then holding down Alt gives the normal behaviour instead. See section 4.10.5 for details.)

If you have a middle mouse button, then you can use it to adjust an existing selection if you selected something slightly wrong. (If you have configured the middle mouse button to paste, then the right mouse button does this instead.) Click the button on the screen, and you can pick up the nearest end of the selection and drag it to somewhere else.


Section 3.1.2: Scrolling the screen back

PuTTY keeps track of text that has scrolled up off the top of the terminal. So if something appears on the screen that you want to read, but it scrolls too fast and it's gone by the time you try to look for it, you can use the scrollbar on the right side of the window to look back up the session history and find it again.

As well as using the scrollbar, you can also page the scrollback up and down by pressing Shift-PgUp and Shift-PgDn. These are still available if you configure the scrollbar to be invisible.

By default the last 200 lines scrolled off the top are preserved for you to look at. You can increase (or decrease) this value using the configuration box; see section 4.6.3.


Section 3.1.3: The System menu

If you click the left mouse button on the icon in the top left corner of PuTTY's window, or click the right mouse button on the title bar, you will see the standard Windows system menu containing items like Minimise, Move, Size and Close.

PuTTY's system menu contains extra program features in addition to the Windows standard options. These extra menu commands are described below.

Section 3.1.3.1: The PuTTY Event Log

Section 3.1.3.2: Starting new sessions

Section 3.1.3.3: Changing your session settings

Section 3.1.3.4: Copy All to Clipboard

Section 3.1.3.5: Clearing and resetting the terminal

Section 3.1.3.6: Full screen mode


Section 3.1.3.1: The PuTTY Event Log

If you choose ‘Event Log’ from the system menu, a small window will pop up in which PuTTY logs significant events during the connection. Most of the events in the log will probably take place during session startup, but a few can occur at any point in the session, and one or two occur right at the end.

You can use the mouse to select one or more lines of the Event Log, and hit the Copy button to copy them to the clipboard. If you are reporting a bug, it's often useful to paste the contents of the Event Log into your bug report.


Section 3.1.3.2: Starting new sessions

PuTTY's system menu provides some shortcut ways to start new sessions:

•	Selecting ‘New Session’ will start a completely new instance of PuTTY, and bring up the configuration box as normal.

•	Selecting ‘Duplicate Session’ will start a session with precisely the same options as your current one - connecting to the same host using the same protocol, with all the same terminal settings and everything.

•	The ‘Saved Sessions’ submenu gives you quick access to any sets of stored session details you have previously saved. See section 4.1.2 for details of how to create saved sessions.


Section 3.1.3.3: Changing your session settings

If you select ‘Change Settings’ from the system menu, PuTTY will display a cut-down version of its initial configuration box. This allows you to adjust most properties of your current session. You can change the terminal size, the font, the actions of various keypresses, the colours, and so on.

Some of the options that are available in the main configuration box are not shown in the cut-down Change Settings box. These are usually options which don't make sense to change in the middle of a session (for example, you can't switch from SSH to Telnet in mid-session).


Section 3.1.3.4: Copy All to Clipboard

This system menu option provides a convenient way to copy the whole contents of the terminal screen and scrollback to the clipboard in one go.


Section 3.1.3.5: Clearing and resetting the terminal

The ‘Clear Scrollback’ option on the system menu tells PuTTY to discard all the lines of text that have been kept after they scrolled off the top of the screen. This might be useful, for example, if you displayed sensitive information and wanted to make sure nobody could look over your shoulder and see it. (Note that this only prevents a casual user from using the scrollbar to view the information; the text is not guaranteed not to still be in PuTTY's memory.)

The ‘Reset Terminal’ option causes a full reset of the terminal emulation. A VT-series terminal is a complex piece of software and can easily get into a state where all the text printed becomes unreadable. (This can happen, for example, if you accidentally output a binary file to your terminal.) If this happens, selecting Reset Terminal should sort it out.


Section 3.1.3.6: Full screen mode

If you find the title bar on a maximised window to be ugly or distracting, you can select Full Screen mode to maximise PuTTY ‘even more’. When you select this, PuTTY will expand to fill the whole screen and its borders, title bar and scrollbar will disappear. (You can configure the scrollbar not to disappear in full-screen mode if you want to keep it; see section 4.6.3.)

When you are in full-screen mode, you can still access the system menu if you click the left mouse button in the extreme top left corner of the screen.


Section 3.2: Creating a log file of your session

For some purposes you may find you want to log everything that appears on your screen. You can do this using the ‘Logging’ panel in the configuration box.

To begin a session log, select ‘Change Settings’ from the system menu and go to the Logging panel. Enter a log file name, and select a logging mode. (You can log all session output including the terminal control sequences, or you can just log the printable text. It depends what you want the log for.) Click ‘Apply’ and your log will be started. Later on, you can go back to the Logging panel and select ‘Logging turned off completely’ to stop logging; then PuTTY will close the log file and you can safely read it.

See section 4.2 for more details and options.


Section 3.3: Altering your character set configuration

If you find that special characters (accented characters, for example) are not being displayed correctly in your PuTTY session, it may be that PuTTY is interpreting the characters sent by the server according to the wrong character set. There are a lot of different character sets available, so it's entirely possible for this to happen.

If you click ‘Change Settings’ and look at the ‘Translation’ panel, you should see a large number of character sets which you can select. Now all you need is to find out which of them you want!


Section 3.4: Using X11 forwarding in SSH

The SSH protocol has the ability to securely forward X Window System applications over your encrypted SSH connection, so that you can run an application on the SSH server machine and have it put its windows up on your local machine without sending any X network traffic in the clear.

In order to use this feature, you will need an X display server for your Windows machine, such as X-Win32 or Exceed. This will probably install itself as display number 0 on your local machine; if it doesn't, the manual for the X server should tell you what it does do.

You should then tick the ‘Enable X11 forwarding’ box in the Tunnels panel (see section 4.17.1) before starting your SSH session. The ‘X display location’ box reads localhost:0 by default, which is the usual display location where your X server will be installed. If that needs changing, then change it.

Now you should be able to log in to the SSH server as normal. To check that X forwarding has been successfully negotiated during connection startup, you can check the PuTTY Event Log (see section 3.1.3.1). It should say something like this:

2001-12-05 17:22:01 Requesting X11 forwarding

2001-12-05 17:22:02 X11 forwarding enabled

If the remote system is Unix or Unix-like, you should also be able to see that the DISPLAY environment variable has been set to point at display 10 or above on the SSH server machine itself:

fred@unixbox:~$ echo $DISPLAY

unixbox:10.0

If this works, you should then be able to run X applications in the remote session and have them display their windows on your PC.

Note that if your PC X server requires authentication to connect, then PuTTY cannot currently support it. If this is a problem for you, you should mail the authors and give details.


Section 3.5: Using port forwarding in SSH

The SSH protocol has the ability to forward arbitrary network connections over your encrypted SSH connection, to avoid the network traffic being sent in clear. For example, you could use this to connect from your home computer to a POP-3 server on a remote machine without your POP-3 password being visible to network sniffers.

In order to use port forwarding to connect from your local machine to a port on a remote server, you need to:

•	Choose a port number on your local machine where PuTTY should listen for incoming connections. There are likely to be plenty of unused port numbers above 3000.

•	Now, before you start your SSH connection, go to the Tunnels panel (see section 4.17.2). Make sure the ‘Local’ radio button is set. Enter the local port number into the ‘Source port’ box. Enter the destination host name and port number into the ‘Destination’ box, separated by a colon (for example, popserver.example.com:110 to connect to a POP-3 server).

•	Now click the ‘Add’ button. The details of your port forwarding should appear in the list box.

Now start your session and log in. (Port forwarding will not be enabled until after you have logged in; otherwise it would be easy to perform completely anonymous network attacks, and gain access to anyone's virtual private network). To check that PuTTY has set up the port forwarding correctly, you can look at the PuTTY Event Log (see section 3.1.3.1). It should say something like this:

2001-12-05 17:22:10 Local port 3110 forwarding to

         popserver.example.com:110

Now if you connect to the source port number on your local PC, you should find that it answers you exactly as if it were the service running on the destination machine. So in this example, you could then configure an e-mail client to use localhost:3110 as a POP-3 server instead of popserver.example.com:110. (Of course, the forwarding will stop happening when your PuTTY session closes down.)

You can also forward ports in the other direction: arrange for a particular port number on the server machine to be forwarded back to your PC as a connection to a service on your PC or near it. To do this, just select the ‘Remote’ radio button instead of the ‘Local’ one. The ‘Source port’ box will now specify a port number on the server (note that most servers will not allow you to use port numbers under 1024 for this purpose).

The source port for a forwarded connection usually does not accept connections from any machine except the SSH client or server machine itself (for local and remote forwardings respectively). There are controls in the Tunnels panel to change this:

•	The ‘Local ports accept connections from other hosts’ option allows you to set up local-to-remote port forwardings in such a way that machines other than your client PC can connect to the forwarded port.

•	The ‘Remote ports do the same’ option does the same thing for remote-to-local port forwardings (so that machines other than the SSH server machine can connect to the forwarded port.) Note that this feature is only available in the SSH 2 protocol, and not all SSH 2 servers support it (OpenSSH 3.0 does not, for example).


Section 3.6: Making raw TCP connections

A lot of Internet protocols are composed of commands and responses in plain text. For example, SMTP (the protocol used to transfer e-mail), NNTP (the protocol used to transfer Usenet news), and HTTP (the protocol used to serve Web pages) all consist of commands in readable plain text.

Sometimes it can be useful to connect directly to one of these services and speak the protocol ‘by hand’, by typing protocol commands and watching the responses. On Unix machines, you can do this using the system's telnet command to connect to the right port number. For example, telnet mailserver.example.com 25 might enable you to talk directly to the SMTP service running on a mail server.

Although the Unix telnet program provides this functionality, the protocol being used is not really Telnet. Really there is no actual protocol at all; the bytes sent down the connection are exactly the ones you type, and the bytes shown on the screen are exactly the ones sent by the server. Unix telnet will attempt to detect or guess whether the service it is talking to is a real Telnet service or not; PuTTY prefers to be told for certain.

In order to make a debugging connection to a service of this type, you simply select the fourth protocol name, ‘Raw’, from the ‘Protocol’ buttons in the ‘Session’ configuration panel. (See section 4.1.1.) You can then enter a host name and a port number, and make the connection.


Chapter 4: Configuring PuTTY

This chapter describes all the configuration options in PuTTY.

PuTTY is configured using the control panel that comes up before you start a session. Some options can also be changed in the middle of a session, by selecting ‘Change Settings’ from the window menu.

Section 4.1: The Session panel

Section 4.2: The Logging panel

Section 4.3: The Terminal panel

Section 4.4: The Keyboard panel

Section 4.5: The Bell panel

Section 4.6: The Window panel

Section 4.7: The Appearance panel

Section 4.8: The Behaviour panel

Section 4.9: The Translation panel

Section 4.10: The Selection panel

Section 4.11: The Colours panel

Section 4.12: The Connection panel

Section 4.13: The Telnet panel

Section 4.14: The Rlogin panel

Section 4.15: The SSH panel

Section 4.16: The Auth panel

Section 4.17: The Tunnels panel

Section 4.18: Storing configuration in a file


Section 4.1: The Session panel

The Session configuration panel contains the basic options you need to specify in order to open a session at all, and also allows you to save your settings to be reloaded later.

Section 4.1.1: The host name section

Section 4.1.2: Loading and storing saved sessions

Section 4.1.3: ‘Close Window on Exit’


Section 4.1.1: The host name section

The top box on the Session panel, labelled ‘Specify your connection by host name’, contains the details that need to be filled in before PuTTY can open a session at all.

•	The ‘Host Name’ box is where you type the name, or the IP address, of the server you want to connect to.

•	The ‘Protocol’ radio buttons let you choose what type of connection you want to make: a raw connection, a Telnet connection, an rlogin connection or an SSH connection. (See section 1.2 for a summary of the differences between SSH, Telnet and rlogin.)

•	The ‘Port’ box lets you specify which port number on the server to connect to. If you select Telnet, Rlogin, or SSH, this box will be filled in automatically to the usual value, and you will only need to change it if you have an unusual server. If you select Raw mode (see section 3.6), you will almost certainly need to fill in the ‘Port’ box.


Section 4.1.2: Loading and storing saved sessions

The next part of the Session configuration panel allows you to save your preferred PuTTY options so they will appear automatically the next time you start PuTTY. It also allows you to create saved sessions, which contain a full set of configuration options plus a host name and protocol. A saved session contains all the information PuTTY needs to start exactly the session you want.

•	To save your default settings: first set up the settings the way you want them saved. Then come back to the Session panel. Select the ‘Default Settings’ entry in the saved sessions list, with a single click. Then press the ‘Save’ button.

Note that PuTTY does not allow you to save a host name into the Default Settings entry. This ensures that when PuTTY is started up, the host name box is always empty, so a user can always just type in a host name and connect.

If there is a specific host you want to store the details of how to connect to, you should create a saved session, which will be separate from the Default Settings.

•	To save a session: first go through the rest of the configuration box setting up all the options you want. Then come back to the Session panel. Enter a name for the saved session in the ‘Saved Sessions’ input box. (The server name is often a good choice for a saved session name.) Then press the ‘Save’ button. Your saved session name should now appear in the list box.

•	To reload a saved session: single-click to select the session name in the list box, and then press the ‘Load’ button. Your saved settings should all appear in the configuration panel.

•	To modify a saved session: first load it as described above. Then make the changes you want. Come back to the Session panel, single-click to select the session name in the list box, and press the ‘Save’ button. The new settings will be saved over the top of the old ones.

•	To start a saved session immediately: double-click on the session name in the list box.

•	To delete a saved session: single-click to select the session name in the list box, and then press the ‘Delete’ button.

Each saved session is independent of the Default Settings configuration. If you change your preferences and update Default Settings, you must also update every saved session separately.


Section 4.1.3: ‘Close Window on Exit’

Finally in the Session panel, there is an option labelled ‘Close Window on Exit’. This controls whether the PuTTY session window disappears as soon as the session inside it terminates. If you are likely to want to copy and paste text out of the session after it has terminated, you should arrange this option to be off.

‘Close Window On Exit’ has three settings. ‘Always’ means always close the window on exit; ‘Never’ means never close on exit (always leave the window open). The third setting, and the default one, is ‘Only on clean exit’. In this mode, a session which terminates normally will cause its window to close, but one which is aborted unexpectedly by network trouble or a confusing message from the server will leave the window up.


Section 4.2: The Logging panel

The Logging configuration panel allows you to save log files of your PuTTY sessions, for debugging, analysis or future reference.

The main option is a radio-button set that specifies whether PuTTY will log anything at all. The options are

•	‘Logging turned off completely’. This is the default option; in this mode PuTTY will not create a log file at all.

•	‘Log printable output only’. In this mode, a log file will be created and written to, but only printable text will be saved into it. The various terminal control codes that are typically sent down an interactive session alongside the printable text will be omitted. This might be a useful mode if you want to read a log file in a text editor and hope to be able to make sense of it.

•	‘Log all session output’. In this mode, everything sent by the server into your terminal session is logged. If you view the log file in a text editor, therefore, you may well find it full of strange control characters. This is a particularly useful mode if you are experiencing problems with PuTTY's terminal handling: you can record everything that went to the terminal, so that someone else can replay the session later in slow motion and watch to see what went wrong.

•	‘Log SSH packet data’. In this mode (which is only used by SSH connections), the SSH message packets sent over the encrypted connection are written to the log file. You might need this to debug a network-level problem, or more likely to send to the PuTTY authors as part of a bug report. BE WARNED that if you log in using a password, the password will appear in the log file, so be sure to edit it out before sending the log file to anyone else!

Section 4.2.1: ‘Log file name’

Section 4.2.2: ‘What to do if the log file already exists’


Section 4.2.1: ‘Log file name’

In this edit box you enter the name of the file you want to log the session to. The ‘Browse’ button will let you look around your file system to find the right place to put the file; or if you already know exactly where you want it to go, you can just type a pathname into the edit box.

There are a few special features in this box. If you use the & character in the file name box, PuTTY will insert details of the current session in the name of the file it actually opens. The precise replacements it will do are:

•	&Y will be replaced by the current year, as four digits.

•	&M will be replaced by the current month, as two digits.

•	&D will be replaced by the current day of the month, as two digits.

•	&T will be replaced by the current time, as six digits (HHMMSS) with no punctuation.

•	&H will be replaced by the host name you are connecting to.

For example, if you enter the host name c:\puttylogs\log-&h-&y&m&d-&t.dat, you will end up with files looking like

log-server1.example.com-20010528-110859.dat

log-unixbox.somewhere.org-20010611-221001.dat


Section 4.2.2: ‘What to do if the log file already exists’

This control allows you to specify what PuTTY should do if it tries to start writing to a log file and it finds the file already exists. You might want to automatically destroy the existing log file and start a new one with the same name. Alternatively, you might want to open the existing log file and add data to the end of it. Finally (the default option), you might not want to have any automatic behaviour, but to ask the user every time the problem comes up.


Section 4.3: The Terminal panel

The Terminal configuration panel allows you to control the behaviour of PuTTY's terminal emulation.

Section 4.3.1: ‘Auto wrap mode initially on’

Section 4.3.2: ‘DEC Origin Mode initially on’

Section 4.3.3: ‘Implicit CR in every LF’

Section 4.3.4: ‘Use background colour to erase screen’

Section 4.3.5: ‘Enable blinking text’

Section 4.3.6: ‘Answerback to ^E’

Section 4.3.7: ‘Local echo’

Section 4.3.8: ‘Local line editing’


Section 4.3.1: ‘Auto wrap mode initially on’

Auto wrap mode controls what happens when text printed in a PuTTY window reaches the right-hand edge of the window.

With auto wrap mode on, if a long line of text reaches the right-hand edge, it will wrap over on to the next line so you can still see all the text. With auto wrap mode off, the cursor will stay at the right-hand edge of the screen, and all the characters in the line will be printed on top of each other.

If you are running a full-screen application and you occasionally find the screen scrolling up when it looks as if it shouldn't, you could try turning this option off.

Auto wrap mode can be turned on and off by control sequences sent by the server. This configuration option only controls the default state. If you modify this option in mid-session using ‘Change Settings’, you will need to reset the terminal (see section 3.1.3.5) before the change takes effect.


Section 4.3.2: ‘DEC Origin Mode initially on’

DEC Origin Mode is a minor option which controls how PuTTY interprets cursor-position control sequences sent by the server.

The server can send a control sequence that restricts the scrolling region of the display. For example, in an editor, the server might reserve a line at the top of the screen and a line at the bottom, and might send a control sequence that causes scrolling operations to affect only the remaining lines.

With DEC Origin Mode on, cursor coordinates are counted from the top of the scrolling region. With it turned off, cursor coordinates are counted from the top of the whole screen regardless of the scrolling region.

It is unlikely you would need to change this option, but if you find a full-screen application is displaying pieces of text in what looks like the wrong part of the screen, you could try turning DEC Origin Mode on to see whether that helps.

DEC Origin Mode can be turned on and off by control sequences sent by the server. This configuration option only controls the default state. If you modify this option in mid-session using ‘Change Settings’, you will need to reset the terminal (see section 3.1.3.5) before the change takes effect.


Section 4.3.3: ‘Implicit CR in every LF’

Most servers send two control characters, CR and LF, to start a new line of the screen. The CR character makes the cursor return to the left-hand side of the screen. The LF character makes the cursor move one line down (and might make the screen scroll).

Some servers only send LF, and expect the terminal to move the cursor over to the left automatically. If you come across a server that does this, you will see a stepped effect on the screen, like this:

First line of text

                  Second line

                             Third line

If this happens to you, try enabling the ‘Implicit CR in every LF’ option, and things might go back to normal:

First line of text

Second line

Third line


Section 4.3.4: ‘Use background colour to erase screen’

Not all terminals agree on what colour to turn the screen when the server sends a ‘clear screen’ sequence. Some terminals believe the screen should always be cleared to the default background colour. Others believe the screen should be cleared to whatever the server has selected as a background colour.

There exist applications that expect both kinds of behaviour. Therefore, PuTTY can be configured to do either.

With this option disabled, screen clearing is always done in the default background colour. With this option enabled, it is done in the current background colour.

Background-colour erase can be turned on and off by control sequences sent by the server. This configuration option only controls the default state. If you modify this option in mid-session using ‘Change Settings’, you will need to reset the terminal (see section 3.1.3.5) before the change takes effect.


Section 4.3.5: ‘Enable blinking text’

The server can ask PuTTY to display text that blinks on and off. This is very distracting, so PuTTY allows you to turn blinking text off completely.

When blinking text is disabled and the server attempts to make some text blink, PuTTY will instead display the text with a bolded background colour.

Blinking text can be turned on and off by control sequences sent by the server. This configuration option only controls the default state. If you modify this option in mid-session using ‘Change Settings’, you will need to reset the terminal (see section 3.1.3.5) before the change takes effect.


Section 4.3.6: ‘Answerback to ^E’

This option controls what PuTTY will send back to the server if the server sends it the ^E enquiry character. Normally it just sends the string ‘PuTTY’.

If you accidentally write the contents of a binary file to your terminal, you will probably find that it contains more than one ^E character, and as a result your next command line will probably read ‘PuTTYPuTTYPuTTY...’ as if you had typed the answerback string multiple times at the keyboard. If you set the answerback string to be empty, this problem should go away, but doing so might cause other problems.


Section 4.3.7: ‘Local echo’

With local echo disabled, characters you type into the PuTTY window are not echoed in the window by PuTTY. They are simply sent to the server. (The server might choose to echo them back to you; this can't be controlled from the PuTTY control panel.)

Some types of session need local echo, and many do not. In its default mode, PuTTY will automatically attempt to deduce whether or not local echo is appropriate for the session you are working in. If you find it has made the wrong decision, you can use this configuration option to override its choice: you can force local echo to be turned on, or force it to be turned off, instead of relying on the automatic detection.


Section 4.3.8: ‘Local line editing’

Normally, every character you type into the PuTTY window is sent immediately to the server the moment you type it.

If you enable local line editing, this changes. PuTTY will let you edit a whole line at a time locally, and the line will only be sent to the server when you press Return. If you make a mistake, you can use the Backspace key to correct it before you press Return, and the server will never see the mistake.

Since it is hard to edit a line locally without being able to see it, local line editing is mostly used in conjunction with local echo (section 4.3.7). This makes it ideal for use in raw mode or when connecting to MUDs or talkers. (Although some more advanced MUDs do occasionally turn local line editing on and turn local echo off, in order to accept a password from the user.)

Some types of session need local line editing, and many do not. In its default mode, PuTTY will automatically attempt to deduce whether or not local line editing is appropriate for the session you are working in. If you find it has made the wrong decision, you can use this configuration option to override its choice: you can force local line editing to be turned on, or force it to be turned off, instead of relying on the automatic detection.


Section 4.4: The Keyboard panel

The Keyboard configuration panel allows you to control the behaviour of the keyboard in PuTTY.

Section 4.4.1: Changing the action of the Backspace key

Section 4.4.2: Changing the action of the Home and End keys

Section 4.4.3: Changing the action of the function keys and keypad

Section 4.4.4: Controlling Application Cursor Keys mode

Section 4.4.5: Controlling Application Keypad mode

Section 4.4.6: Using NetHack keypad mode

Section 4.4.7: Enabling a DEC-like Compose key

Section 4.4.8: ‘Control-Alt is different from AltGr’


Section 4.4.1: Changing the action of the Backspace key

Some terminals believe that the Backspace key should send the same thing to the server as Control-H (ASCII code 8). Other terminals believe that the Backspace key should send ASCII code 127 (usually known as Control-?) so that it can be distinguished from Control-H. This option allows you to choose which code PuTTY generates when you press Backspace.

If you are connecting to a Unix system, you will probably find that the Unix stty command lets you configure which the server expects to see, so you might not need to change which one PuTTY generates. On other systems, the server's expectation might be fixed and you might have no choice but to configure PuTTY.

If you do have the choice, we recommend configuring PuTTY to generate Control-? and configuring the server to expect it, because that allows applications such as emacs to use Control-H for help.


Section 4.4.2: Changing the action of the Home and End keys

The Unix terminal emulator rxvt disagrees with the rest of the world about what character sequences should be sent to the server by the Home and End keys.

xterm, and other terminals, send ESC [1~ for the Home key, and ESC [4~ for the End key. rxvt sends ESC [H for the Home key and ESC [Ow for the End key.

If you find an application on which the Home and End keys aren't working, you could try switching this option to see if it helps.


Section 4.4.3: Changing the action of the function keys and keypad

This option affects the function keys (F1 to F12) and the top row of the numeric keypad.

•	In the default mode, labelled ESC [n~, the function keys generate sequences like ESC [11~, ESC [12~ and so on. This matches the general behaviour of Digital's terminals.

•	In Linux mode, F6 to F12 behave just like the default mode, but F1 to F5 generate ESC [[A through to ESC [[E. This mimics the Linux virtual console.

•	In Xterm R6 mode, F5 to F12 behave like the default mode, but F1 to F4 generate ESC OP through to ESC OS, which are the sequences produced by the top row of the keypad on Digital's terminals.

•	In VT400 mode, all the function keys behave like the default mode, but the actual top row of the numeric keypad generates ESC OP through to ESC OS.

•	In VT100+ mode, the function keys generate ESC OP through to ESC O[

•	In SCO mode, the function keys F1 to F12 generate ESC [M through to ESC [X. Together with shift, they generate ESC [Y through to ESC [j. With control they generate ESC [k through to ESC [v, and with shift and control together they generate ESC [w through to ESC [{.

If you don't know what any of this means, you probably don't need to fiddle with it.


Section 4.4.4: Controlling Application Cursor Keys mode

Application Cursor Keys mode is a way for the server to change the control sequences sent by the arrow keys. In normal mode, the arrow keys send ESC [A through to ESC [D. In application mode, they send ESC OA through to ESC OD.

Application Cursor Keys mode can be turned on and off by the server, depending on the application. PuTTY allows you to configure the initial state, and also allows you to disable application mode completely.


Section 4.4.5: Controlling Application Keypad mode

Application Keypad mode is a way for the server to change the behaviour of the numeric keypad.

In normal mode, the keypad behaves like a normal Windows keypad: with NumLock on, the number keys generate numbers, and with NumLock off they act like the arrow keys and Home, End etc.

In application mode, all the keypad keys send special control sequences, including Num Lock. Num Lock stops behaving like Num Lock and becomes another function key.

Depending on which version of Windows you run, you may find the Num Lock light still flashes on and off every time you press Num Lock, even when application mode is active and Num Lock is acting like a function key. This is unavoidable.

Application keypad mode can be turned on and off by the server, depending on the application. PuTTY allows you to configure the initial state, and also allows you to disable application mode completely.


Section 4.4.6: Using NetHack keypad mode

PuTTY has a special mode for playing NetHack. You can enable it by selecting ‘NetHack’ in the ‘Initial state of numeric keypad’ control.

In this mode, the numeric keypad keys 1-9 generate the NetHack movement commands (hjklyubn). The 5 key generates the . command (do nothing).

Better still, pressing Shift with the keypad keys generates the capital forms of the commands (HJKLYUBN), which tells NetHack to keep moving you in the same direction until you encounter something interesting.

For some reason, this feature only works properly when Num Lock is on. We don't know why.


Section 4.4.7: Enabling a DEC-like Compose key

DEC terminals have a Compose key, which provides an easy-to-remember way of typing accented characters. You press Compose and then type two more characters. The two characters are ‘combined’ to produce an accented character. The choices of character are designed to be easy to remember; for example, composing ‘e’ and ‘`’ produces the ‘è’ character.

If you enable the ‘Application and AltGr act as Compose key’ option, the Windows Application key and the AltGr key will both have this behaviour.


Section 4.4.8: ‘Control-Alt is different from AltGr’

Some old keyboards do not have an AltGr key, which can make it difficult to type some characters. PuTTY can be configured to treat the key combination Ctrl + Left Alt the same way as the AltGr key.

By default, this checkbox is checked, and the key combination Ctrl + Left Alt does something completely different. PuTTY's usual handling of the left Alt key is to prefix the Escape (Control-[) character to whatever character sequence the rest of the keypress would generate. For example, Alt-A generates Escape followed by a. So Alt-Ctrl-A would generate Escape, followed by Control-A.

If you uncheck this box, Ctrl-Alt will become a synonym for AltGr, so you can use it to type extra graphic characters if your keyboard has any.


Section 4.5: The Bell panel

The Bell panel controls the terminal bell feature: the server's ability to cause PuTTY to beep at you.

In the default configuration, when the server sends the character with ASCII code 7 (Control-G), PuTTY will play the Windows Default Beep sound. This is not always what you want the terminal bell feature to do; the Bell panel allows you to configure alternative actions.

Section 4.5.1: ‘Set the style of bell’

Section 4.5.2: ‘Taskbar/caption indication on bell’

Section 4.5.3: ‘Control the bell overload behaviour’


Section 4.5.1: ‘Set the style of bell’

This control allows you to select various different actions to occur on a terminal bell:

•	Selecting ‘None’ disables the bell completely. In this mode, the server can send as many Control-G characters as it likes and nothing at all will happen.

•	‘Play Windows Default Sound’ is the default setting. It causes the Windows ‘Default Beep’ sound to be played. To change what this sound is, or to test it if nothing seems to be happening, use the Sound configurer in the Windows Control Panel.

•	‘Play a custom sound file’ allows you to specify a particular sound file to be used by PuTTY alone, or even by a particular individual PuTTY session. This allows you to distinguish your PuTTY beeps from any other beeps on the system. If you select this option, you will also need to enter the name of your sound file in the edit control ‘Custom sound file to play as a bell’.

•	‘Visual bell’ is a silent alternative to a beeping computer. In this mode, when the server sends a Control-G, the whole PuTTY window will flash white for a fraction of a second.


Section 4.5.2: ‘Taskbar/caption indication on bell’

This feature controls what happens to the PuTTY window's entry in the Windows Taskbar if a bell occurs while the window does not have the input focus.

In the default state (‘Disabled’) nothing unusual happens.

If you select ‘Steady’, then when a bell occurs and the window is not in focus, the window's Taskbar entry and its title bar will change colour to let you know that PuTTY session is asking for your attention. The change of colour will persist until you select the window, so you can leave several PuTTY windows minimised in your terminal, go away from your keyboard, and be sure not to have missed any important beeps when you get back.

‘Flashing’ is even more eye-catching: the Taskbar entry will continuously flash on and off until you select the window.


Section 4.5.3: ‘Control the bell overload behaviour’

A common user error in a terminal session is to accidentally run the Unix command cat (or equivalent) on an inappropriate file type, such as an executable, image file, or ZIP file. This produces a huge stream of non-text characters sent to the terminal, which typically includes a lot of bell characters. As a result of this the terminal often doesn't stop beeping for ten minutes, and everybody else in the office gets annoyed.

To try to avoid this behaviour, or any other cause of excessive beeping, PuTTY includes a bell overload management feature. In the default configuration, receiving more than five bell characters in a two-second period will cause the overload feature to activate. Once the overload feature is active, further bells will have no effect at all, so the rest of your binary file will be sent to the screen in silence. After a period of five seconds during which no further bells are received, the overload feature will turn itself off again and bells will be re-enabled.

If you want this feature completely disabled, you can turn it off using the checkbox ‘Bell is temporarily disabled when over-used’.

Alternatively, if you like the bell overload feature but don't agree with the settings, you can configure the details: how many bells constitute an overload, how short a time period they have to arrive in to do so, and how much silent time is required before the overload feature will deactivate itself.


Section 4.6: The Window panel

The Window configuration panel allows you to control aspects of the PuTTY window.

Section 4.6.1: Setting the size of the PuTTY window

Section 4.6.2: What to do when the window is resized

Section 4.6.3: Controlling scrollback


Section 4.6.1: Setting the size of the PuTTY window

The ‘Rows’ and ‘Columns’ boxes let you set the PuTTY window to a precise size. Of course you can also drag the window to a new size while a session is running.


Section 4.6.2: What to do when the window is resized

These options allow you to control what happens when the user tries to resize the PuTTY window.

When you resize the PuTTY window, one of four things can happen:

•	Nothing (if you have completely disabled resizes).

•	The font size can stay the same and the number of rows and columns in the terminal can change.

•	The number of rows and columns in the terminal can stay the same, and the font size can change.

•	You can allow PuTTY to change either the terminal size or the font size. In this mode it will change the terminal size most of the time, but enlarge the font when you maximise the window.

You can control which of these happens using the ‘Lock terminal size against resizing’ and ‘Lock font size against resizing’ options. If you lock both, the window will refuse to be resized at all. If you lock just the terminal size, the font size will change when you resize the window. If you lock just the font size, the terminal size will change when you resize the window.


Section 4.6.3: Controlling scrollback

These options let you configure the way PuTTY keeps text after it scrolls off the top of the screen (see section 3.1.2).

The ‘Lines of scrollback’ box lets you configure how many lines of text PuTTY keeps. The ‘Display scrollbar’ options allow you to hide the scrollbar (although you can still view the scrollback using Shift-PgUp and Shift-PgDn). You can separately configure whether the scrollbar is shown in full-screen mode and in normal modes.

If you are viewing part of the scrollback when the server sends more text to PuTTY, the screen will revert to showing the current terminal contents. You can disable this behaviour by turning off ‘Reset scrollback on display activity’. You can also make the screen revert when you press a key, by turning on ‘Reset scrollback on keypress’.


Section 4.7: The Appearance panel

The Appearance configuration panel allows you to control aspects of the appearance of PuTTY's window.

Section 4.7.1: Controlling the appearance of the cursor

Section 4.7.2: Controlling the font used in the terminal window

Section 4.7.3: Controlling the window title

Section 4.7.4: ‘Hide mouse pointer when typing in window’

Section 4.7.5: Controlling the window border


Section 4.7.1: Controlling the appearance of the cursor

The ‘Cursor appearance’ option lets you configure the cursor to be a block, an underline, or a vertical line. A block cursor becomes an empty box when the window loses focus; an underline or a vertical line becomes dotted.

The ‘Cursor blinks’ option makes the cursor blink on and off. This works in any of the cursor modes.


Section 4.7.2: Controlling the font used in the terminal window

This option allows you to choose what font, in what size, the PuTTY terminal window uses to display the text in the session. You will be offered a choice from all the fixed-width fonts installed on the system. (VT100-style terminal handling can only deal with fixed- width fonts.)


Section 4.7.3: Controlling the window title

The ‘Window title’ edit box allows you to set the title of the PuTTY window. By default the window title will contain the host name followed by ‘PuTTY’, for example server1.example.com - PuTTY. If you want a different window title, this is where to set it.

PuTTY allows the server to send xterm control sequences which modify the title of the window in mid-session. There is also an xterm sequence to modify the title of the window's icon. This makes sense in a windowing system where the window becomes an icon when minimised, such as Windows 3.1 or most X Window System setups; but in the Windows 95-like user interface it isn't as applicable. By default PuTTY's window title and Taskbar caption will change into the server-supplied icon title if you minimise the PuTTY window, and change back to the server-supplied window title if you restore it. (If the server has not bothered to supply a window or icon title, none of this will happen.) By checking the box marked ‘Avoid ever using icon title’, you can arrange that PuTTY will always display the window title, and completely ignore any icon titles the server sends it.


Section 4.7.4: ‘Hide mouse pointer when typing in window’

If you enable this option, the mouse pointer will disappear if the PuTTY window is selected and you press a key. This way, it will not obscure any of the text in the window while you work in your session. As soon as you move the mouse, the pointer will reappear.

This option is disabled by default, so the mouse pointer remains visible at all times.


Section 4.7.5: Controlling the window border

PuTTY allows you to configure the appearance of the window border to some extent.

The checkbox marked ‘Sunken-edge border’ changes the appearance of the window border to something more like a DOS box: the inside edge of the border is highlighted as if it sank down to meet the surface inside the window. This makes the border a little bit thicker as well. It's hard to describe well. Try it and see if you like it.

You can also configure a completely blank gap between the text in the window and the border, using the ‘Gap between text and window edge’ control. By default this is set at one pixel. You can reduce it to zero, or increase it further.


Section 4.8: The Behaviour panel

The Behaviour configuration panel allows you to control aspects of the behaviour of PuTTY's window.

Section 4.8.1: ‘Warn before closing window’

Section 4.8.2: ‘Window closes on ALT-F4’

Section 4.8.3: ‘System menu appears on ALT-Space’

Section 4.8.4: ‘System menu appears on Alt alone’

Section 4.8.5: ‘Ensure window is always on top’

Section 4.8.6: ‘Full screen on Alt-Enter’


Section 4.8.1: ‘Warn before closing window’

If you press the Close button in a PuTTY window that contains a running session, PuTTY will put up a warning window asking if you really meant to close the window. A window whose session has already terminated can always be closed without a warning.

If you want to be able to close a window quickly, you can disable the ‘Warn before closing window’ option.


Section 4.8.2: ‘Window closes on ALT-F4’

By default, pressing ALT-F4 causes the window to close (or a warning box to appear; see section 4.8.1). If you disable the ‘Window closes on ALT-F4’ option, then pressing ALT-F4 will simply send a key sequence to the server.


Section 4.8.3: ‘System menu appears on ALT-Space’

If this option is enabled, then pressing ALT-Space will bring up the PuTTY window's menu, like clicking on the top left corner. If it is disabled, then pressing ALT-Space will just send ESC SPACE to the server.

Some accessibility programs for Windows may need this option enabling to be able to control PuTTY's window successfully. For instance, Dragon NaturallySpeaking requires it both to open the system menu via voice, and to close, minimise, maximise and restore the window.


Section 4.8.4: ‘System menu appears on Alt alone’

If this option is enabled, then pressing and releasing ALT will bring up the PuTTY window's menu, like clicking on the top left corner. If it is disabled, then pressing and releasing ALT will have no effect.


Section 4.8.5: ‘Ensure window is always on top’

If this option is enabled, the PuTTY window will stay on top of all other windows.


Section 4.8.6: ‘Full screen on Alt-Enter’

If this option is enabled, then pressing Alt-Enter will cause the PuTTY window to become full-screen. Pressing Alt-Enter again will restore the previous window size.

The full-screen feature is also available from the System menu, even when it is configured not to be available on the Alt-Enter key. See section 3.1.3.6.


Section 4.9: The Translation panel

The Translation configuration panel allows you to control the translation between the character set understood by the server and the character set understood by PuTTY.

Section 4.9.1: Controlling character set translation

Section 4.9.2: ‘Caps Lock acts as Cyrillic switch’

Section 4.9.3: Controlling display of line drawing characters


Section 4.9.1: Controlling character set translation

During an interactive session, PuTTY receives a stream of 8-bit bytes from the server, and in order to display them on the screen it needs to know what character set to interpret them in.

There are a lot of character sets to choose from. The ‘Received data assumed to be in which character set’ option lets you select one. By default PuTTY will attempt to choose a character set that is right for your locale as reported by Windows; if it gets it wrong, you can select a different one using this control.

A few notable character sets are:

•	The ISO-8859 series are all standard character sets that include various accented characters appropriate for different sets of languages.

•	The Win125x series are defined by Microsoft, for similar purposes. In particular Win1252 is almost equivalent to ISO-8859-1, but contains a few extra characters such as matched quotes and the Euro symbol.

•	If you want the old IBM PC character set with block graphics and line-drawing characters, you can select ‘CP437’.

•	PuTTY also supports Unicode mode, in which the data coming from the server is interpreted as being in the UTF-8 encoding of Unicode. If you select ‘UTF-8’ as a character set you can use this mode. Not all server-side applications will support it.


Section 4.9.2: ‘Caps Lock acts as Cyrillic switch’

This feature allows you to switch between a US/UK keyboard layout and a Cyrillic keyboard layout by using the Caps Lock key, if you need to type (for example) Russian and English side by side in the same document.

Currently this feature is not expected to work properly if your native keyboard layout is not US or UK.


Section 4.9.3: Controlling display of line drawing characters

VT100-series terminals allow the server to send control sequences that shift temporarily into a separate character set for drawing lines and boxes. PuTTY has a variety of ways to support this capability. In general you should probably try lots of options until you find one that your particular font supports.

•	‘Font has XWindows encoding’ is for use with fonts that have a special encoding, where the lowest 32 character positions (below the ASCII printable range) contain the line-drawing characters. This is unlikely to be the case with any standard Windows font; it will probably only apply to custom-built fonts or fonts that have been automatically converted from the X Window System.

•	‘Use font in both ANSI and OEM modes’ tries to use the same font in two different character sets, to obtain a wider range of characters. This doesn't always work; some fonts claim to be a different size depending on which character set you try to use.

•	‘Use font in OEM mode only’ is more reliable than that, but can miss out other characters from the main character set.

•	‘Poor man's line drawing’ assumes that the font cannot generate the line and box characters at all, so it will use the +, - and | characters to draw approximations to boxes. You should use this option if none of the other options works.

•	‘Unicode mode’ tries to use the box characters that are present in Unicode. For good Unicode-supporting fonts this is probably the most reliable and functional option.


Section 4.10: The Selection panel

The Selection panel allows you to control the way copy and paste work in the PuTTY window.

Section 4.10.1: Controlling the pasting of line drawing characters

Section 4.10.2: Pasting in Rich Text Format

Section 4.10.3: Changing the actions of the mouse buttons

Section 4.10.4: ‘Shift overrides application's use of mouse’

Section 4.10.5: Default selection mode

Section 4.10.6: Configuring word-by-word selection


Section 4.10.1: Controlling the pasting of line drawing characters

By default, when you copy and paste a piece of the PuTTY screen that contains VT100 line and box drawing characters, PuTTY will translate them into the ‘poor man's’ line-drawing characters +, - and |. The checkbox ‘Don't translate line drawing chars’ disables this feature, so line-drawing characters will be pasted as if they were in the normal character set. This will typically mean they come out mostly as q and x, with a scattering of jklmntuvw at the corners. This might be useful if you were trying to recreate the same box layout in another program, for example.


Section 4.10.2: Pasting in Rich Text Format

If you enable ‘Paste to clipboard in RTF as well as plain text’, PuTTY will write formatting information to the clipboard as well as the actual text you copy. Currently the only effect of this will be that if you paste into (say) a word processor, the text will appear in the word processor in the same font PuTTY was using to display it. In future it is likely that other formatting information (bold, underline, colours) will be copied as well.

This option can easily be inconvenient, so by default it is disabled.


Section 4.10.3: Changing the actions of the mouse buttons

PuTTY's copy and paste mechanism is modelled on the Unix xterm application. The X Window System uses a three-button mouse, and the convention is that the left button selects, the right button extends an existing selection, and the middle button pastes.

Windows typically only has two mouse buttons, so in PuTTY's default configuration, the right button pastes, and the middle button (if you have one) extends a selection.

If you have a three-button mouse and you are already used to the xterm arrangement, you can select it using the ‘Action of mouse buttons’ control.


Section 4.10.4: ‘Shift overrides application's use of mouse’

PuTTY allows the server to send control codes that let it take over the mouse and use it for purposes other than copy and paste. Applications which use this feature include the text-mode web browser links, the Usenet newsreader trn version 4, and the file manager mc (Midnight Commander).

When running one of these applications, pressing the mouse buttons no longer performs copy and paste. If you do need to copy and paste, you can still do so if you hold down Shift while you do your mouse clicks.

However, it is possible in theory for applications to even detect and make use of Shift + mouse clicks. We don't know of any applications that do this, but in case someone ever writes one, unchecking the ‘Shift overrides application's use of mouse’ checkbox will cause Shift + mouse clicks to go to the server as well (so that mouse-driven copy and paste will be completely disabled).


Section 4.10.5: Default selection mode

As described in section 3.1.1, PuTTY has two modes of selecting text to be copied to the clipboard. In the default mode (‘Normal’), dragging the mouse from point A to point B selects to the end of the line containing A, all the lines in between, and from the very beginning of the line containing B. In the other mode (‘Rectangular block’), dragging the mouse between two points defines a rectangle, and everything within that rectangle is copied.

Normally, you have to hold down Alt while dragging the mouse to select a rectangular block. Using the ‘Default selection mode’ control, you can set rectangular selection as the default, and then you have to hold down Alt to get the normal behaviour.


Section 4.10.6: Configuring word-by-word selection

PuTTY will select a word at a time in the terminal window if you double-click to begin the drag. This panel allows you to control precisely what is considered to be a word.

Each character is given a class, which is a small number (typically 0, 1 or 2). PuTTY considers a single word to be any number of adjacent characters in the same class. So by modifying the assignment of characters to classes, you can modify the word-by-word selection behaviour.

In the default configuration, the character classes are:

•	Class 0 contains white space and control characters.

•	Class 1 contains most punctuation.

•	Class 2 contains letters, numbers and a few pieces of punctuation (the double quote, minus sign, period, forward slash and underscore).

So, for example, if you assign the @ symbol into character class 2, you will be able to select an e-mail address with just a double click.

In order to adjust these assignments, you start by selecting a group of characters in the list box. Then enter a class number in the edit box below, and press the ‘Set’ button.

This mechanism currently only covers ASCII characters, because it isn't feasible to expand the list to cover the whole of Unicode.


Section 4.11: The Colours panel

The Colours panel allows you to control PuTTY's use of colour.

Section 4.11.1: ‘Bolded text is a different colour’

Section 4.11.2: ‘Attempt to use logical palettes’

Section 4.11.3: Adjusting the colours in the terminal window


Section 4.11.1: ‘Bolded text is a different colour’

When the server sends a control sequence indicating that some text should be displayed in bold, PuTTY can handle this two ways. It can either change the font for a bold version, or use the same font in a brighter colour. This control lets you choose which.

By default the box is checked, so non-bold text is displayed in light grey and bold text is displayed in bright white (and similarly in other colours). If you uncheck the box, bold and non-bold text will be displayed in the same colour, and instead the font will change to indicate the difference.


Section 4.11.2: ‘Attempt to use logical palettes’

Logical palettes are a mechanism by which a Windows application running on an 8-bit colour display can select precisely the colours it wants instead of going with the Windows standard defaults.

If you are not getting the colours you ask for on an 8-bit display, you can try enabling this option. However, be warned that it's never worked very well.


Section 4.11.3: Adjusting the colours in the terminal window

The main colour control allows you to specify exactly what colours things should be displayed in. To modify one of the PuTTY colours, use the list box to select which colour you want to modify. The RGB values for that colour will appear on the right-hand side of the list box. Now, if you press the ‘Modify’ button, you will be presented with a colour selector, in which you can choose a new colour to go in place of the old one.

PuTTY allows you to set the cursor colour, the default foreground and background, and the precise shades of all the ANSI configurable colours (black, red, green, yellow, blue, magenta, cyan, and white). In addition, if you have selected ‘Bolded text is a different colour’, you can also modify the precise shades used for the bold versions of these colours.


Section 4.12: The Connection panel

The Connection panel allows you to configure options that apply to more than one type of connection.

Section 4.12.1: ‘Terminal-type string’

Section 4.12.2: ‘Auto-login username’

Section 4.12.3: Using keepalives to prevent disconnection

Section 4.12.4: ‘Disable Nagle's algorithm’


Section 4.12.1: ‘Terminal-type string’

Most servers you might connect to with PuTTY are designed to be connected to from lots of different types of terminal. In order to send the right control sequences to each one, the server will need to know what type of terminal it is dealing with. Therefore, each of the SSH, Telnet and Rlogin protocols allow a text string to be sent down the connection describing the terminal.

PuTTY attempts to emulate the Unix xterm program, and by default it reflects this by sending xterm as a terminal-type string. If you find this is not doing what you want - perhaps the remote terminal reports ‘Unknown terminal type’ - you could try setting this to something different, such as vt220.

If you're not sure whether a problem is due to the terminal type setting or not, you probably need to consult the manual for your application or your server.


Section 4.12.2: ‘Auto-login username’

All three of the SSH, Telnet and Rlogin protocols allow you to specify what user name you want to log in as, without having to type it explicitly every time. (Some Telnet servers don't support this.)

In this box you can type that user name.


Section 4.12.3: Using keepalives to prevent disconnection

If you find your sessions are closing unexpectedly (‘Connection reset by peer’) after they have been idle for a while, you might want to try using this option.

Some network routers and firewalls need to keep track of all connections through them. Usually, these firewalls will assume a connection is dead if no data is transferred in either direction after a certain time interval. This can cause PuTTY sessions to be unexpectedly closed by the firewall if no traffic is seen in the session for some time.

The keepalive option (‘Seconds between keepalives’) allows you to configure PuTTY to send data through the session at regular intervals, in a way that does not disrupt the actual terminal session. If you find your firewall is cutting idle connections off, you can try entering a non-zero value in this field. The value is measured in seconds; so, for example, if your firewall cuts connections off after ten minutes then you might want to enter 300 seconds (5 minutes) in the box.

Note that keepalives are not always helpful. They help if you have a firewall which drops your connection after an idle period; but if the network between you and the server suffers from breaks in connectivity then keepalives can actually make things worse. If a session is idle, and connectivity is temporarily lost between the endpoints, but the connectivity is restored before either side tries to send anything, then there will be no problem - neither endpoint will notice that anything was wrong. However, if one side does send something during the break, it will repeatedly try to re-send, and eventually give up and abandon the connection. Then when connectivity is restored, the other side will find that the first side doesn't believe there is an open connection any more. Keepalives can make this sort of problem worse, because they increase the probability that PuTTY will attempt to send data during a break in connectivity. Therefore, you might find they help connection loss, or you might find they make it worse, depending on what kind of network problems you have between you and the server.

Keepalives are only supported in Telnet and SSH; the Rlogin and Raw protocols offer no way of implementing them.


Section 4.12.4: ‘Disable Nagle's algorithm’

Nagle's algorithm is a detail of TCP/IP implementations that tries to minimise the number of small data packets sent down a network connection. With Nagle's algorithm enabled, PuTTY's bandwidth usage will be slightly more efficient; with it disabled, you may find you get a faster response to your keystrokes when connecting to some types of server.

The Nagle algorithm is disabled by default.


Section 4.13: The Telnet panel

The Telnet panel allows you to configure options that only apply to Telnet sessions.

Section 4.13.1: ‘Terminal-speed string’

Section 4.13.2: Setting environment variables on the server

Section 4.13.3: ‘Handling of OLD_ENVIRON ambiguity’

Section 4.13.4: Passive and active Telnet negotiation modes

Section 4.13.5: ‘Keyboard sends telnet Backspace and Interrupt’

Section 4.13.6: ‘Return key sends telnet New Line instead of ^M’


Section 4.13.1: ‘Terminal-speed string’

Telnet allows the client to send a text string that describes the terminal speed. PuTTY lets you configure this, in case you find the server is reacting badly to the default value. (I'm not aware of any servers that do have a problem with it.)


Section 4.13.2: Setting environment variables on the server

The Telnet protocol also provides a means for the client to pass environment variables to the server. Many Telnet servers have stopped supporting this feature due to security flaws, but PuTTY still supports it for the benefit of any servers which have found other ways around the security problems than just disabling the whole mechanism.

To add an environment variable to the list transmitted down the connection, you enter the variable name in the ‘Variable’ box, enter its value in the ‘Value’ box, and press the ‘Add’ button. To remove one from the list, select it in the list box and press ‘Remove’.


Section 4.13.3: ‘Handling of OLD_ENVIRON ambiguity’

The original Telnet mechanism for passing environment variables was badly specified. At the time the standard (RFC 1408) was written, BSD telnet implementations were already supporting the feature, and the intention of the standard was to describe the behaviour the BSD implementations were already using.

Sadly there was a typing error in the standard when it was issued, and two vital function codes were specified the wrong way round. BSD implementations did not change, and the standard was not corrected. Therefore, it's possible you might find either BSD or RFC-compliant implementations out there. This switch allows you to choose which one PuTTY claims to be.

The problem was solved by issuing a second standard, defining a new Telnet mechanism called NEW_ENVIRON, which behaved exactly like the original OLD_ENVIRON but was not encumbered by existing implementations. Most Telnet servers now support this, and it's unambiguous. This feature should only be needed if you have trouble passing environment variables to quite an old server.


Section 4.13.4: Passive and active Telnet negotiation modes

In a Telnet connection, there are two types of data passed between the client and the server: actual text, and negotiations about which Telnet extra features to use.

PuTTY can use two different strategies for negotiation:

•	In active mode, PuTTY starts to send negotiations as soon as the connection is opened.

•	In passive mode, PuTTY will wait to negotiate until it sees a negotiation from the server.

The obvious disadvantage of passive mode is that if the server is also operating in a passive mode, then negotiation will never begin at all. For this reason PuTTY defaults to active mode.

However, sometimes passive mode is required in order to successfully get through certain types of firewall and Telnet proxy server. If you have confusing trouble with a firewall, you could try enabling passive mode to see if it helps.


Section 4.13.5: ‘Keyboard sends telnet Backspace and Interrupt’

If this box is checked, the Backspace key on the keyboard will send the Telnet special backspace code, and Control-C will send the Telnet special interrupt code. You probably shouldn't enable this unless you know what you're doing.


Section 4.13.6: ‘Return key sends telnet New Line instead of ^M’

Unlike most other remote login protocols, the Telnet protocol has a special ‘new line’ code that is not the same as the usual line endings of Control-M or Control-J. By default, PuTTY sends the Telnet New Line code when you press Return, instead of sending Control-M as it does in most other protocols.

Most Unix-style Telnet servers don't mind whether they receive Telnet New Line or Control-M; some servers do expect New Line, and some servers prefer to see ^M. If you are seeing surprising behaviour when you press Return in a Telnet session, you might try turning this option off to see if it helps.


Section 4.14: The Rlogin panel

The Rlogin panel allows you to configure options that only apply to Rlogin sessions.

Section 4.14.1: ‘Terminal-speed string’

Section 4.14.2: ‘Local username’


Section 4.14.1: ‘Terminal-speed string’

Like Telnet, Rlogin allows the client to send a text string that describes the terminal speed. PuTTY lets you configure this, in case you find the server is reacting badly to the default value. (I'm not aware of any servers that do have a problem with it.)


Section 4.14.2: ‘Local username’

Rlogin allows an automated (password-free) form of login by means of a file called .rhosts on the server. You put a line in your .rhosts file saying something like jbloggs@pc1.example.com, and then when you make an Rlogin connection the client transmits the username of the user running the Rlogin client. The server checks the username and hostname against .rhosts, and if they match it does not ask for a password.

This only works because Unix systems contain a safeguard to stop a user from pretending to be another user in an Rlogin connection. Rlogin connections have to come from port numbers below 1024, and Unix systems prohibit this to unprivileged processes; so when the server sees a connection from a low-numbered port, it assumes the client end of the connection is held by a privileged (and therefore trusted) process, so it believes the claim of who the user is.

Windows does not have this restriction: any user can initiate an outgoing connection from a low-numbered port. Hence, the Rlogin .rhosts mechanism is completely useless for securely distinguishing several different users on a Windows machine. If you have a .rhosts entry pointing at a Windows PC, you should assume that anyone using that PC can spoof your username in an Rlogin connection and access your account on the server.

The ‘Local username’ control allows you to specify what user name PuTTY should claim you have, in case it doesn't match your Windows user name (or in case you didn't bother to set up a Windows user name).


Section 4.15: The SSH panel

The SSH panel allows you to configure options that only apply to SSH sessions.

Section 4.15.1: Executing a specific command on the server

Section 4.15.2: ‘Don't allocate a pseudo-terminal’

Section 4.15.3: ‘Enable compression’

Section 4.15.4: ‘Preferred SSH protocol version’

Section 4.15.5: ‘Imitate SSH 2 MAC bug’

Section 4.15.6: Encryption algorithm selection


Section 4.15.1: Executing a specific command on the server

In SSH, you don't have to run a general shell session on the server. Instead, you can choose to run a single specific command (such as a mail user agent, for example). If you want to do this, enter the command in the ‘Remote command’ box.


Section 4.15.2: ‘Don't allocate a pseudo-terminal’

When connecting to a Unix system, most interactive shell sessions are run in a pseudo-terminal, which allows the Unix system to pretend it's talking to a real physical terminal device but allows the SSH server to catch all the data coming from that fake device and send it back to the client.

Occasionally you might find you have a need to run a session not in a pseudo-terminal. In PuTTY, this is generally only useful for very specialist purposes; although in Plink (see chapter 7) it is the usual way of working.


Section 4.15.3: ‘Enable compression’

This enables data compression in the SSH connection: data sent by the server is compressed before sending, and decompressed at the client end. Likewise, data sent by PuTTY to the server is compressed first and the server decompresses it at the other end. This can help make the most of a low-bandwidth connection.


Section 4.15.4: ‘Preferred SSH protocol version’

This allows you to select whether you would like to use SSH protocol version 1 or version 2.

PuTTY will attempt to use protocol 1 if the server you connect to does not offer protocol 2, and vice versa.


Section 4.15.5: ‘Imitate SSH 2 MAC bug’

This option should now be unnecessary. It existed in order to work around a bug in early versions (2.3.0 and below) of the SSH server software from ssh.com. The symptom of this problem would be that PuTTY would die unexpectedly at the beginning of the session, saying ‘Incorrect MAC received on packet’.

Current versions of PuTTY attempt to detect these faulty servers and enable the bug compatibility automatically, so you should never need to use this option any more.


Section 4.15.6: Encryption algorithm selection

PuTTY supports a variety of different encryption algorithms, and allows you to choose which one you prefer to use. You can do this by dragging the algorithms up and down in the list box (or moving them using the Up and Down buttons) to specify a preference order. When you make an SSH connection, PuTTY will search down the list from the top until it finds an algorithm supported by the server, and then use that.

If the algorithm PuTTY finds is below the ‘warn below here’ line, you will see a warning box when you make the connection:

The first cipher supported by the server

is single-DES, which is below the configured

warning threshold.

Do you want to continue with this connection?

This warns you that the first available encryption is not a very secure one. Typically you would put the ‘warn below here’ line between the encryptions you consider secure and the ones you consider substandard. By default, PuTTY supplies a preference order intended to reflect a reasonable preference in terms of security and speed.

Single-DES is not supported natively in the SSH 2 draft protocol standards. One or two server implementations do support it, by a non-standard name. PuTTY can use single-DES to interoperate with these servers if you enable the ‘Enable non-standard single-DES in SSH 2’ option; by default this is disabled and PuTTY will stick to the standard.


Section 4.16: The Auth panel

The Auth panel allows you to configure authentication options for SSH sessions.

Section 4.16.1: ‘Attempt TIS or CryptoCard authentication’

Section 4.16.2: ‘Attempt keyboard-interactive authentication’

Section 4.16.3: ‘Allow agent forwarding’

Section 4.16.4: ‘Allow attempted changes of username in SSH2’

Section 4.16.5: ‘Private key file for authentication’


Section 4.16.1: ‘Attempt TIS or CryptoCard authentication’

TIS and CryptoCard authentication are simple challenge/response forms of authentication available in SSH protocol version 1 only. You might use them if you were using S/Key one-time passwords, for example, or if you had a physical security token that generated responses to authentication challenges.

With this switch enabled, PuTTY will attempt these forms of authentication if the server is willing to try them. You will be presented with a challenge string (which will be different every time) and must supply the correct response in order to log in. If your server supports this, you should talk to your system administrator about precisely what form these challenges and responses take.


Section 4.16.2: ‘Attempt keyboard-interactive authentication’

The SSH 2 equivalent of TIS authentication is called ‘keyboard-interactive’. It is a flexible authentication method using an arbitrary sequence of requests and responses; so it is not only useful for challenge/response mechanisms such as S/Key, but it can also be used for (for example) asking the user for a new password when the old one has expired.

PuTTY leaves this option enabled by default, but supplies a switch to turn it off in case you should have trouble with it.


Section 4.16.3: ‘Allow agent forwarding’

This option allows the SSH server to open forwarded connections back to your local copy of Pageant. If you are not running Pageant, this option will do nothing.

See chapter 9 for general information on Pageant, and section 9.4 for information on agent forwarding. Note that there is a security risk involved with enabling this option; see section 9.5 for details.


Section 4.16.4: ‘Allow attempted changes of username in SSH2’

In the SSH 1 protocol, it is impossible to change username after failing to authenticate. So if you mis-type your username at the PuTTY ‘login as:’ prompt, you will not be able to change it except by restarting PuTTY.

The SSH 2 protocol does allow changes of username, in principle, but does not make it mandatory for SSH 2 servers to accept them. In particular, OpenSSH does not accept a change of username; once you have sent one username, it will reject attempts to try to authenticate as another user. (Depending on the version of OpenSSH, it may quietly return failure for all login attempts, or it may send an error message.)

For this reason, PuTTY will by default not prompt you for your username more than once, in case the server complains. If you know your server can cope with it, you can enable the ‘Allow attempted changes of username’ option to modify PuTTY's behaviour.


Section 4.16.5: ‘Private key file for authentication’

This box is where you enter the name of your private key file if you are using public key authentication. See chapter 8 for information about public key authentication in SSH.


Section 4.17: The Tunnels panel

The Tunnels panel allows you to configure tunnelling of other connection types through an SSH connection.

Section 4.17.1: X11 forwarding

Section 4.17.2: Port forwarding

Section 4.17.3: Controlling the visibility of forwarded ports


Section 4.17.1: X11 forwarding

If your server lets you run X Window System applications, X11 forwarding allows you to securely give those applications access to a local X display on your PC.

To enable X11 forwarding, check the ‘Enable X11 forwarding’ box. If your X display is not the primary display on your local machine (which it almost certainly will be unless you have deliberately arranged otherwise), you need to enter its location in the ‘X display location’ box.

See section 3.4 for more information about X11 forwarding.


Section 4.17.2: Port forwarding

Port forwarding allows you to tunnel other types of network connection down an SSH session. See section 3.5 for a general discussion of port forwarding and how it works.

The port forwarding section in the Tunnels panel shows a list of all the port forwardings that PuTTY will try to set up when it connects to the server. By default no port forwardings are set up, so this list is empty.

To add a port forwarding:

•	Set one of the ‘Local’ or ‘Remote’ radio buttons, depending on whether you want to forward a local port to a remote destination (‘Local’) or forward a remote port to a local destination (‘Remote’).

•	Enter a source port number into the ‘Source port’ box. For local forwardings, PuTTY will listen on this port of your PC. For remote forwardings, your SSH server will listen on this port of the remote machine. Note that most servers will not allow you to listen on port numbers less than 1024.

•	Enter a hostname and port number separated by a colon, in the ‘Destination’ box. Connections received on the source port will be directed to this destination. For example, to connect to a POP-3 server, you might enter popserver.example.com:110.

•	Click the ‘Add’ button. Your forwarding details should appear in the list box.

To remove a port forwarding, simply select its details in the list box, and click the ‘Remove’ button.


Section 4.17.3: Controlling the visibility of forwarded ports

The source port for a forwarded connection usually does not accept connections from any machine except the SSH client or server machine itself (for local and remote forwardings respectively). There are controls in the Tunnels panel to change this:

•	The ‘Local ports accept connections from other hosts’ option allows you to set up local-to-remote port forwardings in such a way that machines other than your client PC can connect to the forwarded port.

•	The ‘Remote ports do the same’ option does the same thing for remote-to-local port forwardings (so that machines other than the SSH server machine can connect to the forwarded port.) Note that this feature is only available in the SSH 2 protocol, and not all SSH 2 servers support it (OpenSSH 3.0 does not, for example).


Section 4.18: Storing configuration in a file

PuTTY does not currently support storing its configuration in a file instead of the Registry. However, you can work around this with a couple of batch files.

You will need a file called (say) PUTTY.BAT which imports the contents of a file into the Registry, then runs PuTTY, exports the contents of the Registry back into the file, and deletes the Registry entries. This can all be done using the Regedit command line options, so it's all automatic. Here is what you need in PUTTY.BAT:

@ECHO OFF

regedit /s putty.reg

regedit /s puttyrnd.reg

start /w putty.exe

regedit /e puttynew.reg HKEY_CURRENT_USER\Software\SimonTatham\PuTTY

copy puttynew.reg putty.reg

del puttynew.reg

regedit /s puttydel.reg

This batch file needs two auxiliary files: PUTTYRND.REG which sets up an initial safe location for the PUTTY.RND random seed file, and PUTTYDEL.REG which destroys everything in the Registry once it's been successfully saved back to the file.

Here is PUTTYDEL.REG:

REGEDIT4

[-HKEY_CURRENT_USER\Software\SimonTatham\PuTTY]

Here is an example PUTTYRND.REG file:

REGEDIT4

[HKEY_CURRENT_USER\Software\SimonTatham\PuTTY]

"RandSeedFile"="a:\putty.rnd"

You should replace a:\putty.rnd with the location where you want to store your random number data. If the aim is to carry around PuTTY and its settings on one floppy, you probably want to store it on the floppy.


Chapter 5: Using PSCP to transfer files securely

PSCP, the PuTTY Secure Copy client, is a tool for transferring files securely between computers using an SSH connection.

If you have an SSH 2 server, you might prefer PSFTP (see chapter 6) for interactive use. PSFTP does not in general work with SSH 1 servers, however.

Section 5.1: Starting PSCP

Section 5.2: PSCP Usage

Section 5.3: Secure iXplorer


Section 5.1: Starting PSCP

PSCP is a command line application. This means that you cannot just double-click on its icon to run it and instead you have to bring up a console window. With Windows 95, 98, and ME, this is called an ‘MS-DOS Prompt’ and with Windows NT and 2000 it is called a ‘Command Prompt’. It should be available from the Programs section of your Start Menu.

To start PSCP it will need either to be on your PATH or in your current directory. To add the directory containing PSCP to your PATH environment variable, type into the console window:

set PATH=C:\path\to\putty\directory;%PATH%

This will only work for the lifetime of that particular console window. To set your PATH more permanently on Windows NT, use the Environment tab of the System Control Panel. On Windows 95, 98, and ME, you will need to edit your AUTOEXEC.BAT to include a set command like the one above.


Section 5.2: PSCP Usage

Once you've got a console window to type into, you can just type pscp on its own to bring up a usage message. This tells you the version of PSCP you're using, and gives you a brief summary of how to use PSCP:

Z:\owendadmin>pscp

PuTTY Secure Copy client

Release 0.50

Usage: pscp [options] [user@]host:source target

      pscp [options] source [source...] [user@]host:target

      pscp [options] -ls user@host:filespec

Options:

  -p        preserve file attributes

  -q        quiet, don't show statistics

  -r        copy directories recursively

  -v        show verbose messages

  -P port   connect to specified port

  -pw passw login with specified password

(PSCP's interface is much like the Unix scp command, if you're familiar with that.)

Section 5.2.1: The basics

Section 5.2.2: Options

Section 5.2.3: Return value

Section 5.2.4: Using public key authentication with PSCP


Section 5.2.1: The basics

To receive (a) file(s) from a remote server:

pscp [options] [user@]host:source target

So to copy the file /etc/hosts from the server example.com as user fred to the file c:\temp\example-hosts.txt, you would type:

pscp fred@example.com:/etc/hosts c:\temp\example-hosts.txt

To send (a) file(s) to a remote server:

pscp [options] source [source...] [user@]host:target

So to copy the local file c:\documents\csh-whynot.txt to the server example.com as user fred to the file /tmp/csh-whynot you would type:

pscp c:\documents\csh-whynot.txt fred@example.com:/tmp/csh-whynot

You can use wildcards to transfer multiple files in either direction, like this:

pscp c:\documents\*.doc fred@example.com:docfiles

pscp fred@example.com:source/*.c c:\source

However, in the second case (using a wildcard for multiple remote files) you may see a warning like this:

warning: remote host tried to write to a file called 'terminal.c'

         when we requested a file called '*.c'.

         If this is a wildcard, consider upgrading to SSH 2 or using

         the '-unsafe' option. Renaming of this file has been disallowed.

This is due to a fundamental insecurity in the old-style SCP protocol: the client sends the wildcard string (*.c) to the server, and the server sends back a sequence of file names that match the wildcard pattern. However, there is nothing to stop the server sending back a different pattern and writing over one of your other files: if you request *.c, the server might send back the file name AUTOEXEC.BAT and install a virus for you. Since the wildcard matching rules are decided by the server, the client cannot reliably verify that the filenames sent back match the pattern.

PSCP will attempt to use the newer SFTP protocol (part of SSH 2) where possible, which does not suffer from this security flaw. If you are talking to an SSH 2 server which supports SFTP, you will never see this warning.

If you really need to use a server-side wildcard with an SSH 1 server, you can use the -unsafe command line option with PSCP:

pscp -unsafe fred@example.com:source/*.c c:\source

This will suppress the warning message and the file transfer will happen. However, you should be aware that by using this option you are giving the server the ability to write to any file in the target directory, so you should only use this option if you trust the server administrator not to be malicious (and not to let the server machine be cracked by malicious people).

Section 5.2.1.1: user

Section 5.2.1.2: host

Section 5.2.1.3: source

Section 5.2.1.4: target


Section 5.2.1.1: user

The login name on the remote server. If this is omitted, and host is a PuTTY saved session, PSCP will use any username specified by that saved session. Otherwise, PSCP will attempt to use the local Windows username.


Section 5.2.1.2: host

The name of the remote server, or the name of an existing PuTTY saved session. In the latter case, the session's settings for hostname, port number, cipher type and username will be used.


Section 5.2.1.3: source

One or more source files. Wildcards are allowed. The syntax of wildcards depends on the system to which they apply, so if you are copying from a Windows system to a UNIX system, you should use Windows wildcard syntax (e.g. *.*), but if you are copying from a UNIX system to a Windows system, you would use the wildcard syntax allowed by your UNIX shell (e.g. *).

If the source is a remote server and you do not specify a full pathname (in UNIX, a pathname beginning with a / (slash) character), what you specify as a source will be interpreted relative to your home directory on the remote server.


Section 5.2.1.4: target

The filename or directory to put the file(s). When copying from a remote server to a local host, you may wish simply to place the file(s) in the current directory. To do this, you should specify a target of .. For example:

pscp fred@example.com:/home/tom/.emacs .

...would copy /home/tom/.emacs on the remote server to the current directory.

As with the source parameter, if the target is on a remote server and is not a full path name, it is interpreted relative to your home directory on the remote server.


Section 5.2.2: Options

These are the command line options that PSCP accepts.

Section 5.2.2.1: -p preserve file attributes

Section 5.2.2.2: -q quiet, don't show statistics

Section 5.2.2.3: -r copies directories recursively

Section 5.2.2.4: -v show verbose messages

Section 5.2.2.5: -P port connect to specified port

Section 5.2.2.6: -pw passw login with specified password

Section 5.2.2.7: -batch avoid interactive prompts


Section 5.2.2.1: -p preserve file attributes

By default, files copied with PSCP are timestamped with the date and time they were copied. The -p option preserves the original timestamp on copied files.


Section 5.2.2.2: -q quiet, don't show statistics

By default, PSCP displays a meter displaying the progress of the current transfer:

mibs.tar                  |        168 kB |  84.0 kB/s | ETA: 00:00:13 |  13%

The fields in this display are (from left to right), filename, size (in kilobytes) of file transferred so far, estimate of how fast the file is being transferred (in kilobytes per second), estimated time that the transfer will be complete, and percentage of the file so far transferred. The -q option to PSCP suppresses the printing of these statistics.


Section 5.2.2.3: -r copies directories recursively

By default, PSCP will only copy files. Any directories you specify to copy will be skipped, as will their contents. The -r option tells PSCP to descend into any directories you specify, and to copy them and their contents. This allows you to use PSCP to transfer whole directory structures between machines.


Section 5.2.2.4: -v show verbose messages

The -v option to PSCP makes it print extra information about the file transfer. For example:

Logging in as "fred".

fred@example.com's password:

Sending command: scp -v -f mibs.tar

Connected to example.com

Sending file modes: C0644 1320960 mibs.tar

mibs.tar                  |       1290 kB |  67.9 kB/s | ETA: 00:00:00 | 100%

Remote exit status 0

Closing connection

This information may be useful for debugging problems with PSCP.


Section 5.2.2.5: -P port connect to specified port

If the host you specify is a saved session, PSCP uses any port number specified in that saved session. If not, PSCP uses the default SSH port, 22. The -P option allows you specify the port number to connect to for PSCP's SSH connection.


Section 5.2.2.6: -pw passw login with specified password

If a password is required to connect to the host, PSCP will interactively prompt you for it. However, this may not always be appropriate. If you are running PSCP as part of some automated job, it will not be possible to enter a password by hand. The -pw option to PSCP lets you specify the password to use on the command line.

Since specifying passwords in scripts is a bad idea for security reasons, you might want instead to consider using public-key authentication; see section 5.2.4.


Section 5.2.2.7: -batch avoid interactive prompts

If you use the -batch option, PSCP will never give an interactive prompt while establishing the connection. If the server's host key is invalid, for example (see section 2.2), then the connection will simply be abandoned instead of asking you what to do next.

This may help PSCP's behaviour when it is used in automated scripts: using -batch, if something goes wrong at connection time, the batch job will fail rather than hang.


Section 5.2.3: Return value

PSCP returns an ERRORLEVEL of zero (success) only if the files were correctly transferred. You can test for this in a batch file, using code such as this:

pscp file*.* user@hostname:

if errorlevel 1 echo There was an error


Section 5.2.4: Using public key authentication with PSCP

Like PuTTY, PSCP can authenticate using a public key instead of a password. There are two ways you can do this.

Firstly, PSCP can use PuTTY saved sessions in place of hostnames (see section 5.2.1.2). So you would do this:

•	Run PuTTY, and create a PuTTY saved session (see section 4.1.2) which specifies your private key file (see section 4.16.5). You will probably also want to specify a username to log in as (see section 4.12.2).

•	In PSCP, you can now use the name of the session instead of a hostname: type pscp sessionname:file localfile, where sessionname is replaced by the name of your saved session.

Secondly, PSCP will attempt to authenticate using Pageant if Pageant is running (see chapter 9). So you would do this:

•	Ensure Pageant is running, and has your private key stored in it.

•	Specify a user and host name to PSCP as normal. PSCP will automatically detect Pageant and try to use the keys within it.

For more general information on public-key authentication, see chapter 8.


Section 5.3: Secure iXplorer

Lars Gunnarson has written a graphical interface for PSCP. You can get it from his web site, at www.i-tree.org.


Chapter 6: Using PSFTP to transfer files securely

PSFTP, the PuTTY SFTP client, is a tool for transferring files securely between computers using an SSH connection.

PSFTP differs from PSCP in the following ways:

•	PSCP should work on virtually every SSH server. PSFTP uses the new SFTP protocol, which is a feature of SSH 2 only. (PSCP will also use this protocol if it can, but there is an SSH 1 equivalent it can fall back to if it cannot.)

•	PSFTP allows you to run an interactive file transfer session, much like the Windows ftp program. You can list the contents of directories, browse around the file system, issue multiple get and put commands, and eventually log out. By contrast, PSCP is designed to do a single file transfer operation and immediately terminate.

Section 6.1: Starting PSFTP

Section 6.2: Running PSFTP

Section 6.3: Using public key authentication with PSFTP


Section 6.1: Starting PSFTP

The usual way to start PSFTP is from a command prompt, much like PSCP. To do this, it will need either to be on your PATH or in your current directory. To add the directory containing PSFTP to your PATH environment variable, type into the console window:

set PATH=C:\path\to\putty\directory;%PATH%

Unlike PSCP, however, PSFTP has no complex command-line syntax; you just specify a host name and perhaps a user name:

psftp server.example.com

or perhaps

psftp fred@server.example.com

Alternatively, if you just type psftp on its own (or double-click the PSFTP icon in the Windows GUI), you will see the PSFTP prompt, and a message telling you PSFTP has not connected to any server:

C:\>psftp

psftp: no hostname specified; use "open host.name" to connect

psftp>

At this point you can type open server.example.com or open fred@server.example.com to start a session.

The following sections describe PSFTP's command-line options.

Section 6.1.1: -l: specify a user name

Section 6.1.2: -P: specify a port number

Section 6.1.3: -v: show verbose messages

Section 6.1.4: -pw: specify a password

Section 6.1.5: -b: specify a file containing batch commands

Section 6.1.6: -bc: display batch commands as they are run

Section 6.1.7: -be: continue batch processing on errors

Section 6.1.8: -batch: avoid interactive prompts


Section 6.1.1: -l: specify a user name

The -l option is an alternative way to specify the user name to log in as, on the command line. Instead of typing psftp user@host, you can also type psftp host -l user.

This option does not work in the open command once PSFTP has started.


Section 6.1.2: -P: specify a port number

If the host you specify is a saved session, PSFTP uses any port number specified in that saved session. If not, PSFTP uses the default SSH port, 22. The -P option allows you specify the port number to connect to for PSFTP's SSH connection.


Section 6.1.3: -v: show verbose messages

The -v option to PSFTP makes it print verbose information about the establishing of the SSH connection. The information displayed is equivalent to what is shown in the PuTTY Event Log (section 3.1.3.1).

This information may be useful for debugging problems with PSFTP.


Section 6.1.4: -pw: specify a password

If a password is required to connect to the host, PSFTP will interactively prompt you for it. However, this may not always be appropriate. If you are running PSFTP as part of some automated job, it will not be possible to enter a password by hand. The -pw option to PSFTP lets you specify the password to use on the command line.

Since specifying passwords in scripts is a bad idea for security reasons, you might want instead to consider using public-key authentication; see section 6.3.


Section 6.1.5: -b: specify a file containing batch commands

In normal operation, PSFTP is an interactive program which displays a command line and accepts commands from the keyboard.

If you need to do automated tasks with PSFTP, you would probably prefer to specify a set of commands in advance and have them executed automatically. The -b option allows you to do this. You use it with a file name containing batch commands. For example, you might create a file called myscript.scr containing lines like this:

cd /home/ftp/users/jeff

del jam-old.tar.gz

ren jam.tar.gz jam-old.tar.gz

put jam.tar.gz

chmod a+r jam.tar.gz

quit

and then you could run the script by typing

psftp user@hostname -b myscript.scr

When you run a batch script in this way, PSFTP will abort the script if any command fails to complete successfully. To change this behaviour, you can use the -be option (section 6.1.7).


Section 6.1.6: -bc: display batch commands as they are run

The -bc option alters what PSFTP displays while processing a batch script. With the -bc option, PSFTP will display prompts and commands just as if the commands had been typed at the keyboard. So instead of seeing this:

Sent username "fred"

Remote working directory is /home/fred

Listing directory /home/fred/lib

drwxrwsr-x    4 fred     fred         1024 Sep  6 10:42 .

drwxr-sr-x   25 fred     fred         2048 Dec 14 09:36 ..

drwxrwsr-x    3 fred     fred         1024 Apr 17  2000 jed

lrwxrwxrwx    1 fred     fred           24 Apr 17  2000 timber

drwxrwsr-x    2 fred     fred         1024 Mar 13  2000 trn

you might see this:

Sent username "fred"

Remote working directory is /home/fred

psftp> dir lib

Listing directory /home/fred/lib

drwxrwsr-x    4 fred     fred         1024 Sep  6 10:42 .

drwxr-sr-x   25 fred     fred         2048 Dec 14 09:36 ..

drwxrwsr-x    3 fred     fred         1024 Apr 17  2000 jed

lrwxrwxrwx    1 fred     fred           24 Apr 17  2000 timber

drwxrwsr-x    2 fred     fred         1024 Mar 13  2000 trn

psftp> quit


Section 6.1.7: -be: continue batch processing on errors

When running a batch file, this option causes PSFTP to continue processing even if a command fails to complete successfully.

You might want this to happen if you wanted to delete a file and didn't care if it was already not present, for example.


Section 6.1.8: -batch: avoid interactive prompts

If you use the -batch option, PSFTP will never give an interactive prompt while establishing the connection. If the server's host key is invalid, for example (see section 2.2), then the connection will simply be abandoned instead of asking you what to do next.

This may help PSFTP's behaviour when it is used in automated scripts: using -batch, if something goes wrong at connection time, the batch job will fail rather than hang.


Section 6.2: Running PSFTP

Once you have started your PSFTP session, you will see a psftp> prompt. You can now type commands to perform file-transfer functions. This section lists all the available commands.

Section 6.2.1: General quoting rules for PSFTP commands

Section 6.2.2: The open command: start a session

Section 6.2.3: The quit command: end your session

Section 6.2.4: The help command: get quick online help

Section 6.2.5: The cd and pwd commands: changing the remote working directory

Section 6.2.6: The lcd and lpwd commands: changing the local working directory

Section 6.2.7: The get command: fetch a file from the server

Section 6.2.8: The put command: send a file to the server

Section 6.2.9: The reget and reput commands: resuming file transfers

Section 6.2.10: The dir command: list remote files

Section 6.2.11: The chmod command: change permissions on remote files

Section 6.2.12: The del command: delete remote files

Section 6.2.13: The mkdir command: create remote directories

Section 6.2.14: The rmdir command: remove remote directories

Section 6.2.15: The ren command: rename remote files

Section 6.2.16: The ! command: run a local Windows command


Section 6.2.1: General quoting rules for PSFTP commands

Most PSFTP commands are considered by the PSFTP command interpreter as a sequence of words, separated by spaces. For example, the command ren oldfilename newfilename splits up into three words: ren (the command name), oldfilename (the name of the file to be renamed), and newfilename (the new name to give the file).

Sometimes you will need to specify file names that contain spaces. In order to do this, you can surround the file name with double quotes. This works equally well for local file names and remote file names:

psftp> get "spacey file name.txt" "save it under this name.txt"

The double quotes themselves will not appear as part of the file names; they are removed by PSFTP and their only effect is to stop the spaces inside them from acting as word separators.

If you need to use a double quote (on some types of remote system, such as Unix, you are allowed to use double quotes in file names), you can do this by doubling it. This works both inside and outside double quotes. For example, this command

psftp> ren ""this"" "a file with ""quotes"" in it"

will take a file whose current name is "this" (with a double quote character at the beginning and the end) and rename it to a file whose name is a file with "quotes" in it.

(The one exception to the PSFTP quoting rules is the ! command, which passes its command line straight to Windows without splitting it up into words at all. See section 6.2.16.)


Section 6.2.2: The open command: start a session

If you started PSFTP by double-clicking in the GUI, or just by typing psftp at the command line, you will need to open a connection to an SFTP server before you can issue any other commands (except help and quit).

To create a connection, type open host.name, or if you need to specify a user name as well you can type open user@host.name.

Once you have issued this command, you will not be able to issue it again, even if the command fails (for example, if you mistype the host name or the connection times out). So if the connection is not opened successfully, PSFTP will terminate immediately.


Section 6.2.3: The quit command: end your session

When you have finished your session, type the command quit to terminate PSFTP and return to the command line (or just close the PSFTP console window if you started it from the GUI).

You can also use the bye and exit commands, which have exactly the same effect.


Section 6.2.4: The help command: get quick online help

If you type help, PSFTP will give a short list of the available commands.

If you type help with a command name - for example, help get - then PSFTP will give a short piece of help on that particular command.


Section 6.2.5: The cd and pwd commands: changing the remote working directory

PSFTP maintains a notion of your ‘working directory’ on the server. This is the default directory that other commands will operate on. For example, if you type get filename.dat then PSFTP will look for filename.dat in your remote working directory on the server.

To change your remote working directory, use the cd command. To display your current remote working directory, type pwd.


Section 6.2.6: The lcd and lpwd commands: changing the local working directory

As well as having a working directory on the remote server, PSFTP also has a working directory on your local machine (just like any other Windows process). This is the default local directory that other commands will operate on. For example, if you type get filename.dat then PSFTP will save the resulting file as filename.dat in your local working directory.

To change your local working directory, use the lcd command. To display your current local working directory, type lpwd.


Section 6.2.7: The get command: fetch a file from the server

To download a file from the server and store it on your local PC, you use the get command.

In its simplest form, you just use this with a file name:

get myfile.dat

If you want to store the file locally under a different name, specify the local file name after the remote one:

get myfile.dat newname.dat

This will fetch the file on the server called myfile.dat, but will save it to your local machine under the name newname.dat.


Section 6.2.8: The put command: send a file to the server

To upload a file to the server from your local PC, you use the put command.

In its simplest form, you just use this with a file name:

put myfile.dat

If you want to store the file remotely under a different name, specify the remote file name after the local one:

put myfile.dat newname.dat

This will send the local file called myfile.dat, but will store it on the server under the name newname.dat.


Section 6.2.9: The reget and reput commands: resuming file transfers

If a file transfer fails half way through, and you end up with half the file stored on your disk, you can resume the file transfer using the reget and reput commands. These work exactly like the get and put commands, but they check for the presence of the half-written destination file and start transferring from where the last attempt left off.

The syntax of reget and reput is exactly the same as the syntax of get and put:

reget myfile.dat

reget myfile.dat newname.dat


Section 6.2.10: The dir command: list remote files

To list the files in your remote working directory, just type dir.

You can also list the contents of a different directory by typing dir followed by the directory name:

dir /home/fred

dir sources

The ls command works exactly the same way as dir.


Section 6.2.11: The chmod command: change permissions on remote files

PSFTP allows you to modify the file permissions on files on the server. You do this using the chmod command, which works very much like the Unix chmod command.

The basic syntax is chmod modes file, where modes represents a modification to the file permissions, and file is the filename to modify. For example:

chmod go-rwx,u+w privatefile

chmod a+r publicfile

chmod 640 groupfile

The modes parameter can be a set of octal digits in the Unix style. (If you don't know what this means, you probably don't want to be using it!) Alternatively, it can be a list of permission modifications, separated by commas. Each modification consists of:

•	The people affected by the modification. This can be u (the owning user), g (members of the owning group), or o (everybody else - ‘others’), or some combination of those. It can also be a (‘all’) to affect everybody at once.

•	A + or - sign, indicating whether permissions are to be added or removed.

•	The actual permissions being added or removed. These can be r (permission to read the file), w (permission to write to the file), and x (permission to execute the file, or in the case of a directory, permission to access files within the directory).

So the above examples would do:

•	The first example: go-rwx removes read, write and execute permissions for members of the owning group and everybody else (so the only permissions left are the ones for the file owner). u+w adds write permission for the file owner.

•	The second example: a+r adds read permission for everybody.

In addition to all this, there are a few extra special cases for Unix systems. On non-Unix systems these are unlikely to be useful:

•	You can specify u+s and u-s to add or remove the Unix set-user-ID bit. This is typically only useful for special purposes; refer to your Unix documentation if you're not sure about it.

•	You can specify g+s and g-s to add or remove the Unix set-group-ID bit. On a file, this works similarly to the set-user-ID bit (see your Unix documentation again); on a directory it ensures that files created in the directory are accessible by members of the group that owns the directory.

•	You can specify +t and -t to add or remove the Unix ‘sticky bit’. When applied to a directory, this means that the owner of a file in that directory can delete the file (whereas normally only the owner of the directory would be allowed to).


Section 6.2.12: The del command: delete remote files

To delete a file on the server, type del and then the filename:

del oldfile.dat

The rm command works exactly the same way as del.


Section 6.2.13: The mkdir command: create remote directories

To create a directory on the server, type mkdir and then the directory name:

mkdir newstuff


Section 6.2.14: The rmdir command: remove remote directories

To remove a directory on the server, type rmdir and then the directory name:

rmdir oldstuff

Most SFTP servers will probably refuse to remove a directory if the directory has anything in it, so you will need to delete the contents first.


Section 6.2.15: The ren command: rename remote files

To rename a file on the server, type ren, then the current file name, and then the new file name:

ren oldfile newname

The rename and mv commands work exactly the same way as ren.


Section 6.2.16: The ! command: run a local Windows command

You can run local Windows commands using the ! command. This is the only PSFTP command that is not subject to the command quoting rules given in section 6.2.1. If any command line begins with the ! character, then the rest of the line will be passed straight to Windows without further translation.

For example, if you want to move an existing copy of a file out of the way before downloading an updated version, you might type:

psftp> !ren myfile.dat myfile.bak

psftp> get myfile.dat

using the Windows ren command to rename files on your local PC.


Section 6.3: Using public key authentication with PSFTP

Like PuTTY, PSFTP can authenticate using a public key instead of a password. There are two ways you can do this.

Firstly, PSFTP can use PuTTY saved sessions in place of hostnames. So you might do this:

•	Run PuTTY, and create a PuTTY saved session (see section 4.1.2) which specifies your private key file (see section 4.16.5). You will probably also want to specify a username to log in as (see section 4.12.2).

•	In PSFTP, you can now use the name of the session instead of a hostname: type psftp sessionname, where sessionname is replaced by the name of your saved session.

Secondly, PSFTP will attempt to authenticate using Pageant if Pageant is running (see chapter 9). So you would do this:

•	Ensure Pageant is running, and has your private key stored in it.

•	Specify a user and host name to PSFTP as normal. PSFTP will automatically detect Pageant and try to use the keys within it.

For more general information on public-key authentication, see chapter 8.


Chapter 7: Using the command-line connection tool Plink

Plink (PuTTY Link) is a command-line connection tool similar to UNIX ssh. It is mostly used for automated operations, such as making CVS access a repository on a remote server.

Plink is probably not what you want if you want to run an interactive session in a console window.

Section 7.1: Starting Plink

Section 7.2: Using Plink

Section 7.3: Using Plink in batch files and scripts

Section 7.4: Using Plink with CVS

Section 7.5: Using Plink with WinCVS


Section 7.1: Starting Plink

Plink is a command line application. This means that you cannot just double-click on its icon to run it and instead you have to bring up a console window. In Windows 95, 98, and ME, this is called an ‘MS-DOS Prompt’, and in Windows NT and 2000 it is called a ‘Command Prompt’. It should be available from the Programs section of your Start Menu.

In order to use Plink, the file plink.exe will need either to be on your PATH or in your current directory. To add the directory containing Plink to your PATH environment variable, type into the console window:

set PATH=C:\path\to\putty\directory;%PATH%

This will only work for the lifetime of that particular console window. To set your PATH more permanently on Windows NT, use the Environment tab of the System Control Panel. On Windows 95, 98, and ME, you will need to edit your AUTOEXEC.BAT to include a set command like the one above.


Section 7.2: Using Plink

This section describes the basics of how to use Plink for interactive logins and for automated processes.

Once you've got a console window to type into, you can just type plink on its own to bring up a usage message. This tells you the version of Plink you're using, and gives you a brief summary of how to use Plink:

Z:\sysosd>plink

PuTTY Link: command-line connection utility

Release 0.50

Usage: plink [options] [user@]host [command]

Options:

  -v        show verbose messages

  -ssh      force use of ssh protocol

  -P port   connect to specified port

  -pw passw login with specified password

Once this works, you are ready to use Plink.

Section 7.2.1: Using Plink for interactive logins

Section 7.2.2: Using Plink for automated connections

Section 7.2.3: Options


Section 7.2.1: Using Plink for interactive logins

To make a simple interactive connection to a remote server, just type plink and then the host name:

Z:\sysosd>plink login.example.com

Debian GNU/Linux 2.2 flunky.example.com

flunky login:

You should then be able to log in as normal and run a session. The output sent by the server will be written straight to your command prompt window, which will most likely not interpret terminal control codes in the way the server expects it to. So if you run any full-screen applications, for example, you can expect to see strange characters appearing in your window. Interactive connections like this are not the main point of Plink.

In order to connect with a different protocol, you can give the command line options -ssh, -telnet, -rlogin or -raw. To make an SSH connection, for example:

Z:\sysosd>plink -ssh login.example.com

login as:

If you have already set up a PuTTY saved session, then instead of supplying a host name, you can give the saved session name. This allows you to use public-key authentication, specify a user name, and use most of the other features of PuTTY:

Z:\sysosd>plink my-ssh-session

Sent username "fred"

Authenticating with public key "fred@winbox"

Last login: Thu Dec  6 19:25:33 2001 from :0.0

fred@flunky:~$


Section 7.2.2: Using Plink for automated connections

More typically Plink is used with the SSH protocol, to enable you to talk directly to a program running on the server. To do this you have to ensure Plink is using the SSH protocol. You can do this in several ways:

•	Use the -ssh option as described in section 7.2.1.

•	Set up a PuTTY saved session that describes the server you are connecting to, and that also specifies the protocol as SSH.

•	Set the Windows environment variable PLINK_PROTOCOL to the word ssh.

Usually Plink is not invoked directly by a user, but run automatically by another process. Therefore you typically do not want Plink to prompt you for a user name or a password.

To avoid being prompted for a user name, you can:

•	Use the -l option to specify a user name on the command line. For example, plink login.example.com -l fred.

•	Set up a PuTTY saved session that describes the server you are connecting to, and that also specifies the username to log in as (see section 4.12.2).

To avoid being prompted for a password, you should almost certainly set up public-key authentication. (See chapter 8 for a general introduction to public-key authentication.) Again, you can do this in two ways:

•	Set up a PuTTY saved session that describes the server you are connecting to, and that also specifies a private key file (see section 4.16.5). For this to work without prompting, your private key will need to have no passphrase.

•	Store the private key in Pageant. See chapter 9 for further information.

Once you have done all this, you should be able to run a remote command on the SSH server machine and have it execute automatically with no prompting:

Z:\sysosd>plink login.example.com -l fred echo hello, world

hello, world

Z:\sysosd>

Or, if you have set up a saved session with all the connection details:

Z:\sysosd>plink mysession echo hello, world

hello, world

Z:\sysosd>

Then you can set up other programs to run this Plink command and talk to it as if it were a process on the server machine.

You may also find it useful to use the -batch command-line option; see section 7.2.3.6.


Section 7.2.3: Options

This section describes the command line options that Plink accepts.

Section 7.2.3.1: -v show verbose messages

Section 7.2.3.2: Protocol selection options

Section 7.2.3.3: -P port connect to specified port

Section 7.2.3.4: -pw passw login with specified password

Section 7.2.3.5: -l username login with specified username

Section 7.2.3.6: -batch avoid interactive prompts

Section 7.2.3.7: -m filename read command from a file

Section 7.2.3.8: -L and -R set up port forwarding


Section 7.2.3.1: -v show verbose messages

By default, Plink only displays any password prompts and the output of the remote command. The -v option makes it print extra information about the connection being made, for example:

Server version: SSH-1.5-OpenSSH-1.2.3

We claim version: SSH-1.5-PuTTY

Using SSH protocol version 1

Received public keys

Host key fingerprint is:

      1023 e3:65:44:44:bd:b1:04:59:bc:e2:3d:a1:4d:09:ce:99

Encrypted session key

Using 3DES encryption

Trying to enable encryption...

Successfully started encryption

Sent username "fred".

Sent username "fred"

fred@example.com's password:

This information can be useful for diagnosing problems.


Section 7.2.3.2: Protocol selection options

Plink is most useful when using the SSH protocol. However, it allows you to interface to all the protocols supported by PuTTY. You can specify the option -ssh on the command line to select the SSH protocol; you can also specify -telnet, -rlogin or -raw to select other protocols.


Section 7.2.3.3: -P port connect to specified port

If your server machine is running its SSH service on a port other than the standard one, you can specify an alternative port number to connect to using the -P option, like this:

plink -ssh login.example.com -P 5022


Section 7.2.3.4: -pw passw login with specified password

A simple way to automate a remote login is to supply your password on the Plink command line. This is not recommended for reasons of security. If you possibly can, we recommend you set up public-key authentication instead. See chapter 8 for details.


Section 7.2.3.5: -l username login with specified username

As described in section 7.2.2, you can specify the user name to log in as on the remote server using the -l option. For example, plink login.example.com -l fred.


Section 7.2.3.6: -batch avoid interactive prompts

If you use the -batch option, Plink will never give an interactive prompt while establishing the connection. If the server's host key is invalid, for example (see section 2.2), then the connection will simply be abandoned instead of asking you what to do next.

This may help Plink's behaviour when it is used in automated scripts: using -batch, if something goes wrong at connection time, the batch job will fail rather than hang.


Section 7.2.3.7: -m filename read command from a file

If the command you want to run on the remote server is particularly large, you can read it from a file using the -m option, instead of putting it directly on Plink's command line. On most Unix systems, you can even put multiple lines in this file and execute more than one command in sequence, or a whole shell script.


Section 7.2.3.8: -L and -R set up port forwarding

Plink allows you to use port forwarding just as PuTTY does; if you have set up a PuTTY saved session that specifies port forwardings, and you connect to that session using Plink, then the same port forwardings will be set up.

For convenience, Plink also offers the option to set up port forwarding on the command line. The command-line options work just like the ones in Unix ssh programs.

To forward a local port (say 5110) to a remote destination (say popserver.example.com port 110), you can write:

plink mysession -L 5110:popserver.example.com:110

And to forward a remote port to a local destination, just use the -R option instead of -L:

plink mysession -R 5023:mytelnetserver.myhouse.org:23

For general information on port forwarding, see section 3.5.


Section 7.3: Using Plink in batch files and scripts

Once you have set up Plink to be able to log in to a remote server without any interactive prompting (see section 7.2.2), you can use it for lots of scripting and batch purposes. For example, to start a backup on a remote machine, you might use a command like:

plink root@myserver /etc/backups/do-backup.sh

Or perhaps you want to fetch all system log lines relating to a particular web area:

plink mysession grep /~fjbloggs/ /var/log/httpd/access.log > fredlogs

Any non-interactive command you could usefully run on the server command line, you can run in a batch file using Plink in this way.


Section 7.4: Using Plink with CVS

To use Plink with CVS, you need to set the environment variable CVS_RSH to point to Plink:

set CVS_RSH=\path\to\plink.exe

You also need to arrange to be able to connect to a remote host without any interactive prompts, as described in section 7.2.2.

You should then be able to run CVS as follows:

cvs -d :ext:user@sessionname:/path/to/repository co module

If you specified a username in your saved session, you don't even need to specify the ‘user’ part of this, and you can just say:

cvs -d :ext:sessionname:/path/to/repository co module


Section 7.5: Using Plink with WinCVS

Plink can also be used with WinCVS. Firstly, arrange for Plink to be able to connect to a remote host non-interactively, as described in section 7.2.2.

Then, in WinCVS, bring up the ‘Preferences’ dialogue box from the Admin menu, and switch to the ‘Ports’ tab. Tick the box there labelled ‘Check for an alternate rsh name’ and in the text entry field to the right enter the full path to plink.exe. Select ‘OK’ on the ‘Preferences’ dialogue box.

Next, select ‘Command Line’ from the WinCVS ‘Admin’ menu, and type a CVS command as in section 7.4, for example:

cvs -d :ext:user@hostname:/path/to/repository co module

Select the folder you want to check out to with the ‘Change Folder’ button, and click ‘OK’ to check out your module. Once you've got modules checked out, WinCVS will happily invoke plink from the GUI for CVS operations.


Chapter 8: Using public keys for SSH authentication

Section 8.1: Public key authentication - an introduction

Section 8.2: Using PuTTYgen, the PuTTY key generator

Section 8.3: Getting ready for public key authentication


Section 8.1: Public key authentication - an introduction

Public key authentication is an alternative means of identifying yourself to a login server, instead of typing a password. It is more secure and more flexible, but more difficult to set up.

In conventional password authentication, you prove you are who you claim to be by proving that you know the correct password. The only way to prove you know the password is to tell the server what you think the password is. This means that if the server has been hacked, or spoofed (see section 2.2), an attacker can learn your password.

Public key authentication solves this problem. You generate a key pair, consisting of a public key (which everybody is allowed to know) and a private key (which you keep secret and do not give to anybody). The private key is able to generate signatures. A signature created using your private key cannot be forged by anybody who does not have that key; but anybody who has your public key can verify that a particular signature is genuine.

So you generate a key pair on your own computer, and you copy the public key to the server. Then, when the server asks you to prove who you are, PuTTY can generate a signature using your private key. The server can verify that signature (since it has your public key) and allow you to log in. Now if the server is hacked or spoofed, the attacker does not gain your private key or password; they only gain one signature. And signatures cannot be re-used, so they have gained nothing.

There is a problem with this: if your private key is stored unprotected on your own computer, then anybody who gains access to that will be able to generate signatures as if they were you. So they will be able to log in to your server under your account. For this reason, your private key is usually encrypted when it is stored on your local machine, using a passphrase of your choice. In order to generate a signature, PuTTY must decrypt the key, so you have to type your passphrase.

This can make public-key authentication less convenient than password authentication: every time you log in to the server, instead of typing a short password, you have to type a longer passphrase. One solution to this is to use an authentication agent, a separate program which holds decrypted private keys and generates signatures on request. PuTTY's authentication agent is called Pageant. When you begin a Windows session, you start Pageant and load your public key into it (typing your passphrase once). For the rest of your session, you can start PuTTY any number of times and Pageant will automatically generate signatures without you having to do anything. When you close your Windows session, Pageant shuts down, without ever having stored your decrypted private key on disk. Many people feel this is a good compromise between security and convenience. See chapter 9 for further details.

There is more than one public-key algorithm available. The most common is RSA, but others exist, notably DSA (otherwise known as DSS), the USA's federal Digital Signature Standard. The key types supported by PuTTY are described in section 8.2.2.


Section 8.2: Using PuTTYgen, the PuTTY key generator

PuTTYgen is a key generator. It generates pairs of public and private keys to be used with PuTTY, PSCP, and Plink, as well as the PuTTY authentication agent, Pageant (see chapter 9). PuTTYgen generates RSA keys.

When you run PuTTYgen you will see a window where you have two choices: ‘Generate’, to generate a new public/private key pair, or ‘Load’ to load in an existing private key.

Section 8.2.1: Generating a new key

Section 8.2.2: Selecting the type of key

Section 8.2.3: Selecting the size (strength) of the key

Section 8.2.4: The ‘Generate’ button

Section 8.2.5: The ‘Key fingerprint’ box

Section 8.2.6: Setting a comment for your key

Section 8.2.7: Setting a passphrase for your key

Section 8.2.8: Saving your private key to a disk file

Section 8.2.9: Saving your public key to a disk file

Section 8.2.10: ‘Public key for pasting into authorized_keys file’

Section 8.2.11: Reloading a private key


Section 8.2.1: Generating a new key

This is a general outline of the procedure for generating a new key pair. The following sections describe the process in more detail.

•	First, you need to select which type of key you want to generate, and also select the strength of the key. This is described in more detail in section 8.2.2 and section 8.2.3.

•	Then press the ‘Generate’ button, to actually generate the key. Section 8.2.4 describes this step.

•	Once you have generated the key, select a comment field (section 8.2.6) and a passphrase (section 8.2.7).

•	Now you're ready to save the private key to disk; press the ‘Save private key’ button. (See section 8.2.8).

Your key pair is now ready for use. You may also want to copy the public key to your server, either by copying it out of the ‘Public key for pasting into authorized_keys file’ box (see section 8.2.10), or by using the ‘Save public key’ button (section 8.2.9). However, you don't need to do this immediately; if you want, you can load the private key back into PuTTYgen later (see section 8.2.11) and the public key will be available for copying and pasting again.

section 8.3 describes the typical process of configuring PuTTY to attempt public-key authentication, and configuring your SSH server to accept it.


Section 8.2.2: Selecting the type of key

Before generating a public key using PuTTYgen, you need to select which type of key you need. PuTTYgen currently supports three types of key:

•	An RSA key for use with the SSH 1 protocol.

•	An RSA key for use with the SSH 2 protocol.

•	A DSA key for use with the SSH 2 protocol.

The SSH 1 protocol only supports RSA keys; if you will be connecting using the SSH 1 protocol, you must select the first key type or your key will be completely useless.

The SSH 2 protocol supports more than one key type. The two types supported by PuTTY are RSA and DSA.

The PuTTY developers strongly recommend you use RSA. DSA has an intrinsic weakness which makes it very easy to create a signature which contains enough information to give away the private key! This would allow an attacker to pretend to be you for any number of future sessions. PuTTY's implementation has taken very careful precautions to avoid this weakness, but we cannot be 100% certain we have managed it, and if you have the choice we strongly recommend using RSA keys instead.

If you really need to connect to an SSH server which only supports DSA, then you probably have no choice but to use DSA. If you do use DSA, we recommend you do not use the same key to authenticate with more than one server.


Section 8.2.3: Selecting the size (strength) of the key

The ‘Number of bits’ input box allows you to choose the strength of the key PuTTYgen will generate.

Currently 1024 bits should be sufficient for most purposes.


Section 8.2.4: The ‘Generate’ button

Once you have chosen the type of key you want, and the strength of the key, press the ‘Generate’ button and PuTTYgen will begin the process of actually generating the key.

First, a progress bar will appear and PuTTYgen will ask you to move the mouse around to generate randomness. Wave the mouse in circles over the blank area in the PuTTYgen window, and the progress bar will gradually fill up as PuTTYgen collects enough randomness. You don't need to wave the mouse in particularly imaginative patterns (although it can't hurt); PuTTYgen will collect enough randomness just from the fine detail of exactly how far the mouse has moved each time Windows samples its position.

When the progress bar reaches the end, PuTTYgen will begin creating the key. The progress bar will reset to the start, and gradually move up again to track the progress of the key generation. It will not move evenly, and may occasionally slow down to a stop; this is unfortunately unavoidable, because key generation is a random process and it is impossible to reliably predict how long it will take.

When the key generation is complete, a new set of controls will appear in the window to indicate this.


Section 8.2.5: The ‘Key fingerprint’ box

The ‘Key fingerprint’ box shows you a fingerprint value for the generated key. This is derived cryptographically from the public key value, so it doesn't need to be kept secret.

The fingerprint value is intended to be cryptographically secure, in the sense that it is computationally infeasible for someone to invent a second key with the same fingerprint, or to find a key with a particular fingerprint. So some utilities, such as the Pageant key list box (see section 9.2.1) and the Unix ssh-add utility, will list key fingerprints rather than the whole public key.


Section 8.2.6: Setting a comment for your key

If you have more than one key and use them for different purposes, you don't need to memorise the key fingerprints in order to tell them apart. PuTTY allows you to enter a comment for your key, which will be displayed whenever PuTTY or Pageant asks you for the passphrase.

The default comment format, if you don't specify one, contains the key type and the date of generation, such as rsa-key-20011212. Another commonly used approach is to use your name and the name of the computer the key will be used on, such as simon@simons-pc.

To alter the key comment, just type your comment text into the ‘Key comment’ box before saving the private key. If you want to change the comment later, you can load the private key back into PuTTYgen, change the comment, and save it again.


Section 8.2.7: Setting a passphrase for your key

The ‘Key passphrase’ and ‘Confirm passphrase’ boxes allow you to choose a passphrase for your key. The passphrase will be used to encrypt the key on disk, so you will not be able to use the key without first entering the passphrase.

When you save the key, PuTTY will check that the ‘Key passphrase’ and ‘Confirm passphrase’ boxes both contain exactly the same passphrase, and will refuse to save the key otherwise.

If you leave the passphrase fields blank, the key will be saved unencrypted. You should not do this without good reason; if you do, your private key file on disk will be all an attacker needs to gain access to any machine configured to accept that key. If you want to be able to log in without having to type a passphrase every time, you should consider using Pageant (chapter 9) so that your decrypted key is only held in memory rather than on disk.

Under special circumstances you may genuinely need to use a key with no passphrase; for example, if you need to run an automated batch script that needs to make an SSH connection, you can't be there to type the passphrase. In this case we recommend you generate a special key for each specific batch script (or whatever) that needs one, and on the server side you should arrange that each key is restricted so that it can only be used for that specific purpose. The documentation for your SSH server should explain how to do this (it will probably vary between servers).

Choosing a good passphrase is difficult. Just as you shouldn't use a dictionary word as a password because it's easy for an attacker to run through a whole dictionary, you should not use a song lyric, quotation or other well-known sentence as a passphrase. DiceWare (www.diceware.com) recommends using at least five words each generated randomly by rolling five dice, which gives over 2^64 possible passphrases and is probably not a bad scheme. If you want your passphrase to make grammatical sense, this cuts down the possibilities a lot and you should use a longer one as a result.

Do not forget your passphrase. There is no way to recover it.


Section 8.2.8: Saving your private key to a disk file

Once you have generated a key, set a comment field and set a passphrase, you are ready to save your private key to disk.

Press the ‘Save private key’ button. PuTTYgen will put up a dialog box asking you where to save the file. Select a directory, type in a file name, and press ‘Save’.

This file is the one you will need to tell PuTTY to use for authentication (see section 4.16.5) or tell Pageant to load (see section 9.2.2).


Section 8.2.9: Saving your public key to a disk file

The SSH 2 protocol drafts specify a standard format for storing public keys on disk. Some SSH servers (such as ssh.com's) require a public key in this format in order to accept authentication with the corresponding private key. (Others, such as OpenSSH, use a different format; see section 8.2.10.)

To save your public key in the SSH 2 standard format, press the ‘Save public key’ button in PuTTYgen. PuTTYgen will put up a dialog box asking you where to save the file. Select a directory, type in a file name, and press ‘Save’.

You will then probably want to copy the public key file to your SSH server machine. See section 8.3 for general instructions on configuring public-key authentication once you have generated a key.

If you use this option with an SSH 1 key, the file PuTTYgen saves will contain exactly the same text that appears in the ‘Public key for pasting’ box. This is the only existing standard for SSH 1 public keys.


Section 8.2.10: ‘Public key for pasting into authorized_keys file’

All SSH 1 servers require your public key to be given to it in a one-line format before it will accept authentication with your private key. The OpenSSH server also requires this for SSH 2.

The ‘Public key for pasting into authorized_keys file’ gives the public-key data in the correct one-line format. Typically you will want to select the entire contents of the box using the mouse, press Ctrl+C to copy it to the clipboard, and then paste the data into a PuTTY session which is already connected to the server.

See section 8.3 for general instructions on configuring public-key authentication once you have generated a key.


Section 8.2.11: Reloading a private key

PuTTYgen allows you to load an existing private key file into memory. If you do this, you can then change the passphrase and comment before saving it again; you can also make extra copies of the public key.

To load an existing key, press the ‘Load’ button. PuTTYgen will put up a dialog box where you can browse around the file system and find your key file. Once you select the file, PuTTYgen will ask you for a passphrase (if necessary) and will then display the key details in the same way as if it had just generated the key.


Section 8.3: Getting ready for public key authentication

Connect to your SSH server using PuTTY with the SSH protocol. When the connection succeeds you will be prompted for your user name and password to login. Once logged in, you must configure the server to accept your public key for authentication:

•	If your server is using the SSH 1 protocol, you should change into the .ssh directory and open the file authorized_keys with your favourite editor. (You may have to create this file if this is the first key you have put in it). Then switch to the PuTTYgen window, select all of the text in the ‘Public key for pasting into authorized_keys file’ box (see section 8.2.10), and copy it to the clipboard (Ctrl+C). Then, switch back to the PuTTY window and insert the data into the open file, making sure it ends up all on one line. Save the file.

•	If your server is OpenSSH and is using the SSH 2 protocol, you should follow the same instructions, except that in earlier versions of OpenSSH 2 the file might be called authorized_keys2. (In modern versions the same authorized_keys file is used for both SSH 1 and SSH 2 keys.)

•	If your server is ssh.com's SSH 2 product, you need to save a public key file from PuTTYgen (see section 8.2.9), and copy that into the .ssh2 directory on the server. Then you should go into that .ssh2 directory, and edit (or create) a file called authorization. In this file you should put a line like Key mykey.pub, with mykey.pub replaced by the name of your key file.

•	For other SSH server software, you should refer to the manual for that server.

You may also need to ensure that your home directory, your .ssh directory, and any other files involved (such as authorized_keys, authorized_keys2 or authorization) are not group-writable. You can typically do this by using a command such as

chmod g-w $HOME $HOME/.ssh $HOME/.ssh/authorized_keys

Your server should now be configured to accept authentication using your private key. Now you need to configure PuTTY to attempt authentication using your private key. You can do this in either of two ways:

•	Select the private key in PuTTY's configuration. See section 4.16.5 for details.

•	Load the private key into Pageant (see chapter 9). In this case PuTTY will automatically try to use it for authentication if it can.


Chapter 9: Using Pageant for authentication

Pageant is an SSH authentication agent. It holds your private keys in memory, already decoded, so that you can use them often without needing to type a passphrase.

Section 9.1: Getting started with Pageant

Section 9.2: The Pageant main window

Section 9.3: The Pageant command line

Section 9.4: Using agent forwarding

Section 9.5: Security considerations


Section 9.1: Getting started with Pageant

Before you run Pageant, you need to have a private key. See chapter 8 to find out how to generate and use one.

When you run Pageant, it will put an icon of a computer wearing a hat into the System tray. It will then sit and do nothing, until you load a private key into it.

If you click the Pageant icon with the right mouse button, you will see a menu. Select ‘View Keys’ from this menu. The Pageant main window will appear. (You can also bring this window up by double-clicking on the Pageant icon.)

The Pageant window contains a list box. This shows the private keys Pageant is holding. When you start Pageant, it has no keys, so the list box will be empty. After you add one or more keys, they will show up in the list box.

To add a key to Pageant, press the ‘Add Key’ button. Pageant will bring up a file dialog, labelled ‘Select Private Key File’. Find your private key file in this dialog, and press ‘Open’.

Pageant will now load the private key. If the key is protected by a passphrase, Pageant will ask you to type the passphrase. When the key has been loaded, it will appear in the list in the Pageant window.

Now start PuTTY and open an SSH session to a site that accepts your key. PuTTY will notice that Pageant is running, retrieve the key automatically from Pageant, and use it to authenticate. You can now open as many PuTTY sessions as you like without having to type your passphrase again.

When you want to shut down Pageant, click the right button on the Pageant icon in the System tray, and select ‘Exit’ from the menu. Closing the Pageant main window does not shut down Pageant.


Section 9.2: The Pageant main window

The Pageant main window appears when you left-click on the Pageant system tray icon, or alternatively right-click and select ‘View Keys’ from the menu. You can use it to keep track of what keys are currently loaded into Pageant, and to add new ones or remove the existing keys.

Section 9.2.1: The key list box

Section 9.2.2: The ‘Add Key’ button

Section 9.2.3: The ‘Remove Key’ button


Section 9.2.1: The key list box

The large list box in the Pageant main window lists the private keys that are currently loaded into Pageant. The list might look something like this:

ssh1     1024  22:c3:68:3b:09:41:36:c3:39:83:91:ae:71:b2:0f:04  key1

ssh-rsa  1023  74:63:08:82:95:75:e1:7c:33:31:bb:cb:00:c0:89:8b  key2

For each key, the list box will tell you:

•	The type of the key. Currently, this can be ssh1 (an RSA key for use with the SSH v1 protocol), ssh-rsa (an RSA key for use with the SSH v2 protocol), or ssh-dss (a DSA key for use with the SSH v2 protocol).

•	The size (in bits) of the key.

•	The fingerprint for the public key. This should be the same fingerprint given by PuTTYgen, and (hopefully) also the same fingerprint shown by remote utilities such as ssh-keygen when applied to your authorized_keys file.

•	The comment attached to the key.


Section 9.2.2: The ‘Add Key’ button

To add a key to Pageant by reading it out of a local disk file, press the ‘Add Key’ button in the Pageant main window, or alternatively right-click on the Pageant icon in the system tray and select ‘Add Key’ from there.

Pageant will bring up a file dialog, labelled ‘Select Private Key File’. Find your private key file in this dialog, and press ‘Open’. If you want to add more than one key at once, you can select multiple files using Shift-click (to select several adjacent files) or Ctrl-click (to select non-adjacent files).

Pageant will now load the private key(s). If a key is protected by a passphrase, Pageant will ask you to type the passphrase.

(This is not the only way to add a private key to Pageant. You can also add one from a remote system by using agent forwarding; see section 9.4 for details.)


Section 9.2.3: The ‘Remove Key’ button

If you need to remove a key from Pageant, select that key in the list box, and press the ‘Remove Key’ button. Pageant will remove the key from its memory.

You can apply this to keys you added using the ‘Add Key’ button, or to keys you added remotely using agent forwarding (see section 9.4); it makes no difference.


Section 9.3: The Pageant command line

Pageant can be made to do things automatically when it starts up, by specifying instructions on its command line. If you're starting Pageant from the Windows GUI, you can arrange this by editing the properties of the Windows shortcut that it was started from.

Section 9.3.1: Making Pageant automatically load keys on startup

Section 9.3.2: Making Pageant run another program


Section 9.3.1: Making Pageant automatically load keys on startup

Pageant can automatically load one or more private keys when it starts up, if you provide them on the Pageant command line. Your command line might then look like:

C:\PuTTY\pageant.exe d:\main.key d:\secondary.key

If the keys are stored encrypted, Pageant will request the passphrases on startup.


Section 9.3.2: Making Pageant run another program

You can arrange for Pageant to start another program once it has initialised itself and loaded any keys specified on its command line. This program (perhaps a PuTTY, or a WinCVS making use of Plink, or whatever) will then be able to use the keys Pageant has loaded.

You do this by specifying the -c option followed by the command, like this:

C:\PuTTY\pageant.exe d:\main.key -c C:\PuTTY\putty.exe


Section 9.4: Using agent forwarding

Agent forwarding is a mechanism that allows applications on your SSH server machine to talk to the agent on your client machine.

Note that at present, agent forwarding in SSH2 is only available when your SSH server is OpenSSH. The ssh.com server uses a different agent protocol which they have not published. If you would like PuTTY to be able to support agent forwarding to an ssh.com server, please write to ssh.com and explain to them that they are hurting themselves and their users by keeping their protocol secret.

To enable agent forwarding, first start Pageant. Then set up a PuTTY SSH session in which ‘Allow agent forwarding’ is enabled (see section 4.16.3). Open the session as normal.

If this has worked, your applications on the server should now have access to a Unix domain socket which the SSH server will forward back to PuTTY, and PuTTY will forward on to the agent. To check that this has actually happened, you can try this command on Unix server machines:

unixbox:~$ echo $SSH_AUTH_SOCK

/tmp/ssh-XXNP18Jz/agent.28794

unixbox:~$

If the result line comes up blank, agent forwarding has not been enabled at all.

Now if you run ssh on the server and use it to connect through to another server that accepts one of the keys in Pageant, you should be able to log in without a password:

unixbox:~$ ssh -v otherunixbox

[...]

debug: next auth method to try is publickey

debug: userauth_pubkey_agent: trying agent key my-putty-key

debug: ssh-userauth2 successful: method publickey

[...]

If you enable agent forwarding on that SSH connection as well (see the manual for your server-side SSH client to find out how to do this), your authentication keys will still be available on the next machine you connect to - two SSH connections away from where they're actually stored.

In addition, if you have a private key on one of the SSH servers, you can send it all the way back to Pageant using the local ssh-add command:

unixbox:~$ ssh-add ~/.ssh/id_rsa

Need passphrase for /home/fred/.ssh/id_rsa

Enter passphrase for /home/fred/.ssh/id_rsa:

Identity added: /home/fred/.ssh/id_rsa (/home/simon/.ssh/id_rsa)

unixbox:~$

and then it's available to every machine that has agent forwarding available (not just the ones downstream of the place you added it).


Section 9.5: Security considerations

Using Pageant for public-key authentication gives you the convenience of being able to open multiple SSH sessions without having to type a passphrase every time, but also gives you the security benefit of never storing a decrypted private key on disk. Many people feel this is a good compromise between security and convenience.

It is a compromise, however. Holding your decrypted private keys in Pageant is better than storing them in easy-to-find disk files, but still less secure than not storing them anywhere at all. This is for two reasons:

•	Windows unfortunately provides no way to protect pieces of memory from being written to the system swap file. So if Pageant is holding your private keys for a long period of time, it's possible that decrypted private key data may be written to the system swap file, and an attacker who gained access to your hard disk later on might be able to recover that data. (However, if you stored an unencrypted key in a disk file they would certainly be able to recover it.)

•	Although, like most modern operating systems, Windows prevents programs from accidentally accessing one another's memory space, it does allow programs to access one another's memory space deliberately, for special purposes such as debugging. This means that if you allow a virus, trojan, or other malicious program on to your Windows system while Pageant is running, it could access the memory of the Pageant process, extract your decrypted authentication keys, and send them back to its master.

Similarly, use of agent forwarding is a security improvement on other methods of one-touch authentication, but not perfect. Holding your keys in Pageant on your Windows box has a security advantage over holding them on the remote server machine itself (either in an agent or just unencrypted on disk), because if the server machine ever sees your unencrypted private key then the sysadmin or anyone who cracks the machine can steal the keys and pretend to be you for as long as they want.

However, the sysadmin of the server machine can always pretend to be you on that machine. So if you forward your agent to a server machine, then the sysadmin of that machine can access the forwarded agent connection and request signatures from your public keys, and can therefore log in to other machines as you. They can only do this to a limited extent - when the agent forwarding disappears they lose the ability - but using Pageant doesn't actually prevent the sysadmin (or hackers) on the server from doing this.

Therefore, if you don't trust the sysadmin of a server machine, you should never use agent forwarding to that machine. (Of course you also shouldn't store private keys on that machine, type passphrases into it, or log into other machines from it in any way at all; Pageant is hardly unique in this respect.)


Appendix A: PuTTY FAQ

This FAQ is published on the PuTTY web site, and also provided as an appendix in the manual.

Section A.1: Features supported in PuTTY

Section A.2: Ports to other operating systems

Section A.3: Embedding PuTTY in other programs

Section A.4: Details of PuTTY's operation

Section A.5: HOWTO questions

Section A.6: Troubleshooting

Section A.7: Security questions

Section A.8: Administrative questions


Section A.1: Features supported in PuTTY

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:

•	try the 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 since the latest version, it should be available in the development snapshots, in which case testing will be very welcome.

•	try the Wishlist page, and see if you can find the feature there. If it's on there, it probably hasn't been implemented.

Question A.1.1: Does PuTTY support SSH v2?

Question A.1.2: Does PuTTY support reading OpenSSH or ssh.com SSHv2 private key files?

Question A.1.3: Does PuTTY support SSH v1?

Question A.1.4: Does PuTTY support local echo?

Question A.1.5: Does PuTTY support storing its settings in a disk file?

Question A.1.6: Does PuTTY support full-screen mode, like a DOS box?

Question A.1.7: Does PuTTY have the ability to remember my password so I don't have to type it every time?

Question A.1.8: Is there an option to turn off the annoying host key prompts?

Question A.1.9: Will you write an SSH server for the PuTTY suite, to go with the client?


Question A.1.1: Does PuTTY support SSH v2?

Yes. SSH v2 support has been available in PuTTY since version 0.50. However, currently the default SSH protocol is v1; to select SSH v2 if your server supports both, go to the SSH panel and change the Preferred SSH protocol version option.

Public key authentication (both RSA and DSA) in SSH v2 is new in version 0.52.


Question A.1.2: Does PuTTY support reading OpenSSH or ssh.com SSHv2 private key files?

Not at present. OpenSSH and ssh.com have totally different formats for private key files, and neither one is particularly pleasant, so PuTTY has its own. We do plan to write a converter at some stage.


Question A.1.3: Does PuTTY support SSH v1?

Yes. SSH 1 support has always been available in PuTTY.


Question A.1.4: Does PuTTY support 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 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’.


Question A.1.5: Does PuTTY support storing its settings in a disk file?

Not at present, although section 4.18 in the documentation gives a method of achieving the same effect.


Question A.1.6: Does PuTTY support full-screen mode, like a DOS box?

Yes; this is a new feature in version 0.52.


Question A.1.7: Does PuTTY have the ability to 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 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.


Question A.1.8: Is there an option to turn off the 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 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.


Question A.1.9: 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.


Section A.2: Ports to other operating systems

The eventual goal is for PuTTY to be a multi-platform program, able to run on at least Windows, MacOS and Unix. Whether this will actually ever happen I have no idea, but it is the plan. A Mac port has been started, but is only half-finished and currently not moving very fast.

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 is for this porting layer to evolve naturally as part of the process of doing the first port. One particularly nasty part of this will be separating the many configuration options into platform-dependent and platform-independent ones; for example, the options controlling when the Windows System menu appears will be pretty much meaningless under X11 or perhaps other windowing systems, whereas Telnet Passive Mode is universal and shouldn't need to be specified once for each platform.

Question A.2.1: Will there be a port to Windows CE?

Question A.2.2: Is there a port to Windows 3.1?

Question A.2.3: Will there be a port to the Mac?

Question A.2.4: Will there be a port to Unix?

Question A.2.5: Will there be a port to EPOC?


Question A.2.1: Will there be a port to Windows CE?

Probably not in the particularly near future. Despite sharing large parts of the Windows API, in practice WinCE doesn't appear to be significantly easier to port to than a totally different operating system.

However, PuTTY on portable devices would clearly be a useful thing, so in the long term I hope there will be a WinCE port.


Question A.2.2: Is there a port to 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 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!


Question A.2.3: Will there be a port to the Mac?

A Mac port was started once and is half-finished, but development has been static for some time and the main PuTTY code has moved on, so it's not clear how quickly development would resume even if developer effort were available.


Question A.2.4: Will there be a port to Unix?

I hope so, if only so that I can have an xterm-like program that supports exactly the same terminal emulation as PuTTY. If and when we do do a Unix port, it will have a local-terminal back end so it can be used like an xterm, rather than only being usable as a network utility.


Question A.2.5: 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 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.


Section A.3: Embedding PuTTY in other programs

Question A.3.1: Is the SSH or Telnet code available as a DLL?

Question A.3.2: Is the SSH or Telnet code available as a Visual Basic component?

Question A.3.3: How can I use PuTTY to make an SSH connection from within another program?


Question A.3.1: 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.


Question A.3.2: 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.


Question A.3.3: 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.


Section A.4: Details of PuTTY's operation

Question A.4.1: What terminal type does PuTTY use?

Question A.4.2: Where does PuTTY store its data?


Question A.4.1: What terminal type does PuTTY use?

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.


Question A.4.2: Where does PuTTY store its data?

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


Section A.5: HOWTO questions

Question A.5.1: How can I make PuTTY start up maximised?

Question A.5.2: How can I create a Windows shortcut to start a particular saved session directly?

Question A.5.3: How can I start an SSH session straight from the command line?

Question A.5.4: How do I copy and paste between PuTTY and other Windows applications?

Question A.5.5: How do I use X forwarding and port forwarding? I can't find the Tunnels panel.

Question A.5.6: How do I use all PuTTY's features (public keys, port forwarding, SSH v2, etc.) in PSCP, PSFTP and Plink?

Question A.5.7: How do I use PSCP.EXE? When I double-click it gives me a command prompt window which then closes instantly.

Question A.5.8: How do I use PSCP to copy a file whose name has spaces in?


Question A.5.1: How can I make PuTTY start up maximised?

Create a Windows shortcut to start PuTTY from, and set it as ‘Run Maximized’.


Question A.5.2: How can I create a Windows shortcut to start a particular saved session directly?

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 @mysession


Question A.5.3: How can I start an SSH session straight from the command line?

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.5.2.


Question A.5.4: How do 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 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.


Question A.5.5: How do I use X forwarding and port forwarding? I can't find the Tunnels panel.

This is a new feature in version 0.52. You should upgrade.


Question A.5.6: How do I use all PuTTY's features (public keys, port forwarding, SSH v2, etc.) in PSCP, PSFTP and Plink?

The command-line tools are currently rather short of command line options to enable this sort of thing. However, 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!).


Question A.5.7: 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 chapter 5 in the documentation for more details.


Question A.5.8: 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:

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" .


Section A.6: Troubleshooting

Question A.6.1: Why do I see ‘Incorrect MAC received on packet’?

Question A.6.2: I clicked on a colour in the Colours panel, and the colour didn't change in my terminal.

Question A.6.3: Plink on Windows 95 says it can't find WS2_32.DLL.

Question A.6.4: My PuTTY sessions close after an hour and tell me ‘Server failed host key check’.

Question A.6.5: After trying to establish an SSH 2 connection, PuTTY says ‘Out of memory’ and dies.

Question A.6.6: When I run full-colour applications, I see areas of black space where colour ought to be.

Question A.6.7: When I change some terminal settings, nothing happens.

Question A.6.8: I can't type characters that require the AltGr key.

Question A.6.9: My PuTTY sessions unexpectedly close after they are idle for a while.

Question A.6.10: PuTTY's network connections time out too quickly when network connectivity is temporarily lost.

Question A.6.11: When I cat a binary file, I get `PuTTYPuTTYPuTTY' on my command line.

Question A.6.12: When I cat a binary file, my window title changes to a nonsense string.

Question A.6.13: My keyboard stops working once PuTTY displays the password prompt.

Question A.6.14: One or more function keys don't do what I expected in a server-side application.


Question A.6.1: Why do I see ‘Incorrect MAC received on packet’?

This is due to a bug in old SSH 2 servers distributed by ssh.com. 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.


Question A.6.2: I clicked on a colour in the 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 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.


Question A.6.3: Plink on Windows 95 says it can't find 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/


Question A.6.4: My PuTTY sessions close after an hour and tell me ‘Server failed host key check’.

This is a bug in all versions of PuTTY up to and including 0.51. SSH v2 servers from ssh.com will require the key exchange to be repeated one hour after the start of the connection, and PuTTY will get this wrong.

Upgrade to version 0.52 and the problem should go away.


Question A.6.5: After trying to establish an SSH 2 connection, PuTTY says ‘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 ‘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.


Question A.6.6: When I run full-colour applications, I see areas of black space where colour ought to be.

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, it won't take effect until you reset the terminal (see question A.6.7).


Question A.6.7: When I change some terminal settings, nothing happens.

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.

If you want to 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.


Question A.6.8: I can't type characters that require the AltGr key.

In PuTTY version 0.51, the AltGr key was broken. Upgrade to version 0.52.


Question A.6.9: My PuTTY sessions unexpectedly close after they are idle for a while.

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.12.3 in the documentation for more discussion of this.


Question A.6.10: PuTTY's network connections time out too quickly when 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 change is

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\

  MSTCP\MaxDataRetries

(it must be of type DWORD in Win95, or String in Win98/ME).

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.

Set the key's value to something like 10. This will cause Windows to try harder to keep connections alive instead of abandoning them.


Question A.6.11: When I 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.


Question A.6.12: When I 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.


Question A.6.13: My keyboard stops working once PuTTY displays the 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 long your password is, which might be valuable information.


Question A.6.14: One or more 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 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.


Section A.7: Security questions

Question A.7.1: Is it safe for me to download PuTTY and use it on a public PC?

Question A.7.2: What does PuTTY leave on a system? How can I clean up after it?

Question A.7.3: How come PuTTY now supports DSA, when the website used to say how insecure it was?


Question A.7.1: Is it safe for me to download PuTTY and use it on a public PC?

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).


Question A.7.2: What does PuTTY leave on a system? How can I clean up after it?

PuTTY will leave some Registry entries, and a random seed file, on the PC (see question A.4.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.


Question A.7.3: How come PuTTY now supports DSA, when the website used to say how insecure it was?

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.


Section A.8: Administrative questions

Question A.8.1: Would you like me to register you a nicer domain name?

Question A.8.2: Would you like free web hosting for the PuTTY web site?

Question A.8.3: Why don't you move PuTTY to SourceForge?

Question A.8.4: Why can't I subscribe to the putty-bugs mailing list?

Question A.8.5: If putty-bugs isn't a general-subscription mailing list, what is?

Question A.8.6: How can I donate to PuTTY development?

Question A.8.7: Where can I buy silly putty?

Question A.8.8: How do I pronounce PuTTY?


Question A.8.1: Would you like me to register you a nicer domain name?

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.


Question A.8.2: Would you like free web hosting for the PuTTY web site?

We already have some, thanks.


Question A.8.3: Why don't you move PuTTY to SourceForge?

Partly, because we don't want to move the web site location (see question A.8.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.


Question A.8.4: Why can't I subscribe to the putty-bugs mailing list?

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.


Question A.8.5: If putty-bugs isn't a general-subscription mailing list, what is?

There isn't one, that we know of.

If someone else wants to set up a mailing list for PuTTY users to help each other with common problems, that would be fine with us; but the PuTTY team would almost certainly not have the time to read it, so any questions the list couldn't answer would have to be forwarded on to us by the questioner. In any case, it's probably better to use the established newsgroup comp.security.ssh for this purpose.


Question A.8.6: How can I donate to PuTTY development?

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 go to www.e-gold.com, and 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 2000), 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.


Question A.8.7: Where can I buy silly putty?

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.


Question A.8.8: How do I pronounce PuTTY?

Exactly like the normal word ‘putty’. Just like the stuff you put on window frames. (One of the reasons it's called PuTTY is because it makes Windows usable. :-)


Appendix B: Feedback and bug reporting

This is a guide to providing feedback to the PuTTY development team. It is provided as both a web page on the PuTTY site, and an appendix in the PuTTY manual.

Section B.1 gives some general guidelines for sending any kind of e-mail to the development team. Following sections give more specific guidelines for particular types of e-mail, such as bug reports and feature requests.

Section B.1: General guidelines

Section B.2: Reporting bugs

Section B.3: Requesting extra features

Section B.4: Requesting features that have already been requested

Section B.5: Web server administration

Section B.6: Asking permission for things

Section B.7: Mirroring the PuTTY web site

Section B.8: Praise and compliments

Section B.9: E-mail address


Section B.1: General guidelines

The PuTTY development team gets a lot of mail. If you can possibly solve your own problem by reading the manual, reading the FAQ, reading the web site, asking a fellow user, perhaps posting on the newsgroup comp.security.ssh, or some other means, then it would make our lives much easier.

If the volume of e-mail really gets on top of us and we can't find time to answer it all, then the first e-mails we discard will be the ones from people who don't look as if they have made a reasonable effort to solve their own problems. This is not intended to cause offence; it's occasionally a necessary response to a serious problem. We get a lot of e-mail. Really.

Also, the PuTTY contact email address is a mailing list. For this reason, e-mails larger than 40Kb will be held for inspection by the list administrator, and will not be allowed through unless they really appear to be worth their large size. Therefore:

•	Don't send your bug report as a Word document. Word documents are roughly fifty times larger than writing the same report in plain text. In addition, most of the PuTTY team read their e-mail on Unix machines, so copying the attachment to a Windows box to run Word is very inconvenient. Not only that, but several of us don't even have a copy of Word!

•	Don't mail large screen shots without checking with us first. Sending a screen shot of an error box is almost certainly unnecessary when you could just tell us in plain text what the error was. Sending a full-screen shot is sometimes useful, but it's probably still wise to check with us before sending it.

•	If you want to send us a screen shot, or any other kind of large data file, it is much more convenient for us if you can put the file on a web site and send us the URL. That way (a) we don't have to download it at all if it doesn't look necessary; and (b) only one member of the team needs to download it, instead of it being automatically sent to everyone on the mailing list.

•	If you must mail a screen shot, don't send it as a .BMP file. BMPs have no compression and they are much larger than other image formats such as PNG, TIFF and GIF. Convert the file to a properly compressed image format before sending it.


Section B.2: Reporting bugs

If you think you have found a bug in PuTTY, your first steps should be:

•	Check the Wishlist page on the PuTTY website, and see if we already know about the problem. If we do, it is almost certainly not necessary to mail us about it, unless you think you have extra information that might be helpful to us in fixing it. (Of course, if we actually need specific extra information about a particular bug, the Wishlist page will say so.)

•	Check the Change Log on the PuTTY website, and see if we have already fixed the bug in the development snapshots.

•	Check the FAQ on the PuTTY website (also provided as appendix A in the manual), and see if it answers your question. The FAQ lists the most common things which people think are bugs, but which aren't bugs.

•	Download the latest development snapshot and see if the problem still happens with that. This really is worth doing. As a general rule we aren't very interested in bugs that appear in the release version but not in the development version, because that usually means they are bugs we have already fixed. On the other hand, if you can find a bug in the development version that doesn't appear in the release, that's likely to be a new bug we've introduced since the release and we're definitely interested in it.

If none of those options solved your problem, and you still need to report a bug to us, it is useful if you include some general information:

•	Tell us what version of PuTTY you are running. To find this out, use the "About PuTTY" option from the System menu. Please do not just tell us ‘I'm running the latest version’; e-mail can be delayed and it may not be obvious which version was the latest at the time you sent the message.

•	Tell us what version of what OS you are running PuTTY on.

•	Tell us what protocol you are connecting with: SSH, Telnet, Rlogin or Raw mode.

•	Tell us what kind of server you are connecting to; what OS, and if possible what SSH server (if you're using SSH). You can get some of this information from the PuTTY Event Log (see section 3.1.3.1 in the manual).

•	Send us the contents of the PuTTY Event Log, unless you have a specific reason not to (for example, if it contains confidential information that you think we should be able to solve your problem without needing to know).

•	Try to give us as much information as you can to help us see the problem for ourselves. If possible, give us a step-by-step sequence of precise instructions for reproducing the fault.

•	Don't just tell us that PuTTY ‘does the wrong thing’; tell us exactly and precisely what it did, and also tell us exactly and precisely what you think it should have done instead. Some people tell us PuTTY does the wrong thing, and it turns out that it was doing the right thing and their expectations were wrong. Help to avoid this problem by telling us exactly what you think it should have done, and exactly what it did do.

•	If you think you can, you're welcome to try to fix the problem yourself. A patch to the code which fixes a bug is an excellent addition to a bug report. However, a patch is never a substitute for a good bug report; if your patch is wrong or inappropriate, and you haven't supplied us with full information about the actual bug, then we won't be able to find a better solution.

•	http://www.chiark.greenend.org.uk/~sgtatham/bugs.html is an article on how to report bugs effectively in general. If your bug report is particularly unclear, we may ask you to go away, read this article, and then report the bug again.


Section B.3: Requesting extra features

If you want to request a new feature in PuTTY, the very first things you should do are:

•	Check the Wishlist page on the PuTTY website, and see if your feature is already on the list. If it is, it probably won't achieve very much to repeat the request. (But see section B.4 if you want to persuade us to give your particular feature higher priority.)

•	Check the Change Log on the PuTTY website, and see if we have already added your feature in the development snapshots. If it isn't clear, download the latest development snapshot and see if the feature is present. If it is, then it will also be in the next release and there is no need to mail us at all.

If you can't find your feature in either the development snapshots or the Wishlist, then you probably do need to submit a feature request. Since the PuTTY authors are very busy, it helps if you try to do some of the work for us:

•	Do as much of the design as you can. Think about ‘corner cases’; think about how your feature interacts with other existing features. Think about the user interface; if you can't come up with a simple and intuitive interface to your feature, you shouldn't be surprised if we can't either. Always imagine whether it's possible for there to be more than one, or less than one, of something you'd assumed there would be one of. (For example, if you were to want PuTTY to put an icon in the System tray rather than the Taskbar, you should think about what happens if there's more than one PuTTY active; how would the user tell which was which?)

•	If you can program, it may be worth offering to write the feature yourself and send us a patch. However, it is likely to be helpful if you confer with us first; there may be design issues you haven't thought of, or we may be about to make big changes to the code which your patch would clash with, or something. If you check with the maintainers first, there is a better chance of your code actually being usable.


Section B.4: Requesting features that have already been requested

If a feature is already listed on the Wishlist, then it usually means we would like to add it to PuTTY at some point. However, this may not be in the near future. If there's a feature on the Wishlist which you would like to see in the near future, there are several things you can do to try to increase its priority level:

•	Mail us and vote for it. (Be sure to mention that you've seen it on the Wishlist, or we might think you haven't even read the Wishlist). This probably won't have very much effect; if a huge number of people vote for something then it may make a difference, but one or two extra votes for a particular feature are unlikely to change our priority list immediately. Also, don't expect a reply.

•	Offer us money if we do the work sooner rather than later. This sometimes works, but not always. The PuTTY team all have full-time jobs and we're doing all of this work in our free time; we may sometimes be willing to give up some more of our free time in exchange for some money, but if you try to bribe us for a big feature it's entirely possible that we simply won't have the time to spare - whether you pay us or not. (Also, we don't accept bribes to add bad features to the Wishlist, because our desire to provide high-quality software to the users comes first.)

•	Offer to help us write the code. This is probably the only way to get a feature implemented quickly, if it's a big one that we don't have time to do ourselves.


Section B.5: Web server administration

If the PuTTY web site is down (Connection Timed Out), please don't bother mailing us to tell us about it. Most of us read our e-mail on the same machines that host the web site, so if those machines are down then we will notice before we read our e-mail. So there's no point telling us our servers are down.

Of course, if the web site has some other error (Connection Refused, 404 Not Found, 403 Forbidden, or something else) then we might not have noticed and it might still be worth telling us about it.


Section B.6: Asking permission for things

PuTTY is distributed under the MIT Licence (see appendix C for details). This means you can do almost anything you like with our software, our source code, and our documentation. The only things you aren't allowed to do are to remove our copyright notices or the licence text itself, or to hold us legally responsible if something goes wrong.

So if you want permission to include PuTTY on a magazine cover disk, or as part of a collection of useful software on a CD or a web site, then permission is already granted. You don't have to mail us and ask. Just go ahead and do it. We don't mind.

If you want to use parts of the PuTTY source code in another program, then it might be worth mailing us to talk about technical details, but if all you want is to ask permission then you don't need to bother. You already have permission.


Section B.7: Mirroring the PuTTY web site

All mirrors of the PuTTY web site are welcome. Please don't bother asking us for permission before setting up a mirror. You already have permission. We are always happy to have more mirrors.

If you mail us after you have set up the mirror, and remember to let us know which country your mirror is in, then we'll add it to the Mirrors page on the PuTTY website.

If you have technical questions about the process of mirroring, then you might want to mail us before setting up the mirror; but if you just want to ask for permission, you don't need to. You already have permission.


Section B.8: Praise and compliments

One of the most rewarding things about maintaining free software is getting e-mails that just say ‘thanks’. We are always happy to receive e-mails of this type.

Regrettably we don't have time to answer them all in person. If you mail us a compliment and don't receive a reply, please don't think we've ignored you. We did receive it and we were happy about it; we just didn't have time to tell you so personally.

To everyone who's ever sent us praise and compliments, in the past and the future: you're welcome!


Section B.9: E-mail address

The actual address to mail is <putty@projects.tartarus.org>.


Appendix C: PuTTY Licence

PuTTY is copyright 1997-2001 Simon Tatham.

Portions copyright Robert de Bath, Joris van Rantwijk, Delian Delchev, Andreas Schultz, Jeroen Massar, Wez Furlong, Nicolas Barry, and CORE SDI S.A.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.