Previous | Contents | Index | Next
xterm-style mouse reportingThis 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.
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.
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 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.
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 the new settings under a different name, you can enter the new name in the ÿSaved Sessionsÿ box, or single-click to select a session name in the list box to overwrite that session. To save ÿDefault Settingsÿ, you must single-click the name before saving.
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.
Saved sessions are stored in the Registry, at the location
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions
If you need to store them in a file, you could try the method described in section 4.21.
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, or restart the session, you should arrange for 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, but inactive). 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.
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
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
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.
These options only apply if SSH packet data is being logged.
The following options allow particularly sensitive portions of unencrypted packets to be automatically left out of the log file. They are only intended to deter casual nosiness; an attacker could glean a lot of useful information from even these obfuscated logs (e.g., length of password).
When checked, password fields are removed from the log of transmitted packets. (This includes any user responses to challenge-response authentication methods such as ÿkeyboard-interactiveÿ.) This does not include X11 authentication data if using X11 forwarding.
Note that this will only omit data that PuTTY knows to be a password. However, if you start another login session within your PuTTY session, for instance, any password used will appear in the clear in the packet log. The next option may be of use to protect against this.
This option is enabled by default.
When checked, all ÿsession dataÿ is omitted; this is defined as data in terminal sessions and in forwarded channels (TCP, X11, and authentication agent). This will usually substantially reduce the size of the resulting log file.
This option is disabled by default.
The Terminal configuration panel allows you to control the behaviour of PuTTY's terminal emulation.
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 controls the default state, which will be restored when you reset the terminal (see section 3.1.3.6). However, if you modify this option in mid-session using ÿChange Settingsÿ, it will take effect immediately.
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 controls the default state, which will be restored when you reset the terminal (see section 3.1.3.6). However, if you modify this option in mid-session using ÿChange Settingsÿ, it will take effect immediately.
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
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 controls the default state, which will be restored when you reset the terminal (see section 3.1.3.6). However, if you modify this option in mid-session using ÿChange Settingsÿ, it will take effect immediately.
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 controls the default state, which will be restored when you reset the terminal (see section 3.1.3.6). However, if you modify this option in mid-session using ÿChange Settingsÿ, it will take effect immediately.
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.
Note that this is not the feature of PuTTY which the server will typically use to determine your terminal type. That feature is the ÿTerminal-type stringÿ in the Connection panel; see section 4.13.1 for details.
You can include control characters in the answerback string using ^C notation. (Use ^~ to get a literal ^.)
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.
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.
A lot of VT100-compatible terminals support printing under control of the remote server. PuTTY supports this feature as well, but it is turned off by default.
To enable remote-controlled printing, choose a printer from the ÿPrinter to send ANSI printer output toÿ drop-down list box. This should allow you to select from all the printers you have installed drivers for on your computer. Alternatively, you can type the network name of a networked printer (for example, \\printserver\printer1) even if you haven't already installed a driver for it on your own machine.
When the remote server attempts to print some data, PuTTY will send that data to the printer raw - without translating it, attempting to format it, or doing anything else to it. It is up to you to ensure your remote server knows what type of printer it is talking to.
Since PuTTY sends data to the printer raw, it cannot offer options such as portrait versus landscape, print quality, or paper tray selection. All these things would be done by your PC printer driver (which PuTTY bypasses); if you need them done, you will have to find a way to configure your remote server to do them.
To disable remote printing again, choose ÿNone (printing disabled)ÿ from the printer selection list. This is the default state.
The Keyboard configuration panel allows you to control the behaviour of the keyboard in PuTTY.
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.
(Typing Shift-Backspace will cause PuTTY to send whichever code isn't configured here as the default.)
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.
This option affects the function keys (F1 to F12) and the top row of the numeric keypad.
ESC [n~, the function keys generate sequences like ESC [11~, ESC [12~ and so on. This matches the general behaviour of Digital's terminals.
ESC [[A through to ESC [[E. This mimics the Linux virtual console.
ESC OP through to ESC OS, which are the sequences produced by the top row of the keypad on Digital's terminals.
ESC OP through to ESC OS.
ESC OP through to ESC O[
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.
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.
You can also disable application cursor keys mode completely, using the ÿFeaturesÿ configuration panel; see section 4.6.1.
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.
You can also disable application keypad mode completely, using the ÿFeaturesÿ configuration panel; see section 4.6.1.
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.
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 your keyboard has a Windows Application key, it acts as a Compose key in PuTTY. Alternatively, if you enable the ÿAltGr acts as Compose keyÿ option, the AltGr key will become a Compose key.
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.
(However, Ctrl-Alt will never act as a Compose key, regardless of the setting of ÿAltGr acts as Compose keyÿ described in section 4.4.7.)
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.
This control allows you to select various different actions to occur on a terminal 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.
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.
Bell overload mode is always deactivated by any keypress in the terminal. This means it can respond to large unexpected streams of data, but does not interfere with ordinary command-line activities that generate beeps (such as filename completion).
PuTTY's terminal emulation is very highly featured, and can do a lot of things under remote server control. Some of these features can cause problems due to buggy or strangely configured server applications.
The Features configuration panel allows you to disable some of PuTTY's more advanced terminal features, in case they cause trouble.
Application keypad mode (see section 4.4.5) and application cursor keys mode (see section 4.4.4) alter the behaviour of the keypad and cursor keys. Some applications enable these modes but then do not deal correctly with the modified keys. You can force these modes to be permanently disabled no matter what the server tries to do.
xterm-style mouse reporting
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).
If you find this feature inconvenient, you can disable it using the ÿDisable xterm-style mouse reportingÿ control. With this box ticked, the mouse will always do copy and paste in the normal way.
Note that even if the application takes over the mouse, you can still manage PuTTY's copy and paste by holding down the Shift key while you select and paste, unless you have deliberately turned this feature off (see section 4.11.3).
PuTTY has the ability to change the terminal's size and position in response to commands from the server. If you find PuTTY is doing this unexpectedly or inconveniently, you can tell PuTTY not to respond to those server commands.
Many terminals, including PuTTY, support an ÿalternate screenÿ. This is the same size as the ordinary terminal screen, but separate. Typically a screen-based program such as a text editor might switch the terminal to the alternate screen before starting up. Then at the end of the run, it switches back to the primary screen, and you see the screen contents just as they were before starting the editor.
Some people prefer this not to happen. If you want your editor to run in the same screen as the rest of your terminal activity, you can disable the alternate screen feature completely.
PuTTY has the ability to change the window title in response to commands from the server. If you find PuTTY is doing this unexpectedly or inconveniently, you can tell PuTTY not to respond to those server commands.
PuTTY can optionally provide the xterm service of allowing server applications to find out the local window title. This feature is disabled by default, but you can turn it on if you really want it.
NOTE that this feature is a potential security hazard. If a malicious application can write data to your terminal (for example, if you merely cat a file owned by someone else on the server machine), it can change your window title (unless you have disabled this as mentioned in section 4.6.5) and then use this service to have the new window title sent back to the server as if typed at the keyboard. This allows an attacker to fake keypresses and potentially cause your server-side applications to do things you didn't want. Therefore this feature is disabled by default, and we recommend you do not turn it on unless you really know what you are doing.
Normally, when PuTTY receives character 127 (^?) from the server, it will perform a ÿdestructive backspaceÿ: move the cursor one space left and delete the character under it. This can apparently cause problems in some applications, so PuTTY provides the ability to configure character 127 to perform a normal backspace (without deleting a character) instead.
PuTTY has the ability to change its character set configuration in response to commands from the server. Some programs send these commands unexpectedly or inconveniently. In particular, BitchX (an IRC client) seems to have a habit of reconfiguring the character set to something other than the user intended.
If you find that accented characters are not showing up the way you expect them to, particularly if you're running BitchX, you could try disabling the remote character set configuration commands.
The Window configuration panel allows you to control aspects 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.
These options allow you to control what happens when the user tries to resize the PuTTY window using its window furniture.
There are four options here:
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 the keyboard as described in section 3.1.2). 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ÿ.
When this option is enabled, the contents of the terminal screen will be pushed into the scrollback when a server-side application clears the screen, so that your scrollback will contain a better record of what was on your screen in the past.
If the application switches to the alternate screen (see section 4.6.4 for more about this), then the contents of the primary screen will be visible in the scrollback until the application switches back again.
This option is enabled by default.
The Appearance configuration panel allows you to control aspects of the appearance of PuTTY's window.
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.
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.)
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.
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.
The Behaviour configuration panel allows you to control aspects of the behaviour of PuTTY's window.
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 (unless this is disabled - see section 4.6.5); the title string set here is therefore only the initial window title.
As well as the window title, 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 only uses the server-supplied window title, and ignores the icon title entirely. If for some reason you want to see both titles, check the box marked ÿSeparate window and icon titlesÿ. If you do this, 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.)
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.
By default, pressing ALT-F4 causes the window to close (or a warning box to appear; see section 4.9.2). If you disable the ÿWindow closes on ALT-F4ÿ option, then pressing ALT-F4 will simply send a key sequence to the server.
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.
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.
If this option is enabled, the PuTTY window will stay on top of all other windows.
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.7.
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.
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:
If you need support for a numeric code page which is not listed in the drop-down list, such as code page 866, then you can try entering its name manually (CP866 for example) in the list box. If the underlying version of Windows has the appropriate translation table installed, PuTTY will use it.
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.
VT100-series terminals allow the server to send control sequences that shift temporarily into a separate character set for drawing simple lines and boxes. However, there are a variety of ways in which PuTTY can attempt to find appropriate characters, and the right one to use depends on the locally configured font. In general you should probably try lots of options until you find one that your particular font supports.
+, - and | characters to draw approximations to boxes. You should use this option if none of the other options works.
By default, when you copy and paste a piece of the PuTTY screen that contains VT100 line and box drawing characters, PuTTY will paste them in the form they appear on the screen: either Unicode line drawing code points, or the ÿpoor man'sÿ line-drawing characters +, - and |. The checkbox ÿCopy and paste VT100 line drawing chars as lqqqkÿ disables this feature, so line-drawing characters will be pasted as the ASCII characters that were printed to produce them. 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.
Note that this option only applies to line-drawing characters which were printed by using the VT100 mechanism. Line-drawing characters that were received as Unicode code points will paste as Unicode always.
The Selection panel allows you to control the way copy and paste work in the PuTTY window.
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.
PuTTY's copy and paste mechanism is by default 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 often only has two mouse buttons, so in PuTTY's default configuration (ÿCompromiseÿ), 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.
Alternatively, with the ÿWindowsÿ option selected, the middle button extends, and the right button brings up a context menu (on which one of the options is ÿPasteÿ). (This context menu is always available by holding down Ctrl and right-clicking, regardless of the setting of this option.)
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).
If you want to prevent the application from taking over the mouse at all, you can do this using the Features control panel; see section 4.6.2.
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.
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:
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.
Character class definitions can be modified by control sequences sent by the server. This configuration option controls the default state, which will be restored when you reset the terminal (see section 3.1.3.6). However, if you modify this option in mid-session using ÿChange Settingsÿ, it will take effect immediately.
The Colours panel allows you to control PuTTY's use of 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.
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.
Enabling this option will cause PuTTY to ignore the configured colours for ÿDefault Background/Foregroundÿ and ÿCursor Colour/Textÿ (see section 4.12.4), instead going with the system-wide defaults.
Note that non-bold and bold text will be the same colour if this option is enabled. You might want to change to indicating bold text by font changes (see section 4.12.1).
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). You can also modify the precise shades used for the bold versions of these colours; these are used to display bold text if you have selected ÿBolded text is a different colourÿ, and can also be used if the server asks specifically to use them. (Note that ÿDefault Bold Backgroundÿ is not the background colour used for bold text; it is only used if the server specifically asks for a bold background.)
The Connection panel allows you to configure options that apply to more than one type of connection.
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 system 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.
The Telnet, Rlogin, and SSH protocols allow the client to specify terminal speeds to the server.
This parameter does not affect the actual speed of the connection, which is always ÿas fast as possibleÿ; it is just a hint that is sometimes used by server software to modify its behaviour. For instance, if a slow speed is indicated, the server may switch to a less bandwidth-hungry display mode.
The value is usually meaningless in a network environment, but PuTTY lets you configure it, in case you find the server is reacting badly to the default value.
The format is a pair of numbers separated by a comma, for instance, 38400,38400. The first number represents the output speed (from the server) in bits per second, and the second is the input speed (to the server). (Only the first is used in the Rlogin protocol.)
This option has no effect on Raw connections.
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.
The Telnet protocol 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.
Version 2 of the SSH protocol also provides a similar mechanism, which is easier to implement without security flaws. Newer SSH2 servers are more likely to support it than older ones.
This configuration data is not used in the SSHv1, rlogin or raw protocols.
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ÿ.
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. (For an alternative, see section 4.13.7.)
Note that if you are using SSH1 and the server has a bug that makes it unable to deal with SSH1 ignore messages (see section 4.20.1), enabling keepalives will have no effect.
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.
NOTE: TCP keepalives should not be confused with the application-level keepalives described in section 4.13.5. If in doubt, you probably want application-level keepalives; TCP keepalives are provided for completeness.
The idea of TCP keepalives is similar to application-level keepalives, and the same caveats apply. The main differences are:
TCP keepalives may be more useful for ensuring that half-open connections are terminated than for keeping a connection alive.
TCP keepalives are disabled by default.
The Proxy panel allows you to configure PuTTY to use various types of proxy in order to make its network connections. The settings in this panel affect the primary network connection forming your PuTTY session, but also any extra connections made as a result of SSH port forwarding (see section 3.5).
The ÿProxy typeÿ radio buttons allow you to configure what type of proxy you want PuTTY to use for its network connections. The default setting is ÿNoneÿ; in this mode no proxy is used for any connection.
CONNECT command, as documented in RFC 2817.
connect myhost.com 22 to connect through to an external host. Selecting ÿTelnetÿ allows you to tell PuTTY to use this type of proxy.
Typically you will only need to use a proxy to connect to non-local parts of your network; for example, your proxy might be required for connections outside your company's internal network. In the ÿExclude Hosts/IPsÿ box you can enter ranges of IP addresses, or ranges of DNS names, for which PuTTY will avoid using the proxy and make a direct connection instead.
The ÿExclude Hosts/IPsÿ box may contain more than one exclusion range, separated by commas. Each range can be an IP address or a DNS name, with a * character allowing wildcards. For example:
*.example.com
This excludes any host with a name ending in .example.com from proxying.
192.168.88.*
This excludes any host with an IP address starting with 192.168.88 from proxying.
192.168.88.*,*.example.com
This excludes both of the above ranges at once.
Connections to the local host (the host name localhost, and any loopback IP address) are never proxied, even if the proxy exclude list does not explicitly contain them. It is very unlikely that this behaviour would ever cause problems, but if it does you can change it by enabling ÿConsider proxying local host connectionsÿ.
Note that if you are doing DNS at the proxy (see section 4.14.3), you should make sure that your proxy exclusion settings do not depend on knowing the IP address of a host. If the name is passed on to the proxy without PuTTY looking it up, it will never know the IP address and cannot check it against your list.
If you are using a proxy to access a private network, it can make a difference whether DNS name resolution is performed by PuTTY itself (on the client machine) or performed by the proxy.
The ÿDo DNS name lookup at proxy endÿ configuration option allows you to control this. If you set it to ÿNoÿ, PuTTY will always do its own DNS, and will always pass an IP address to the proxy. If you set it to ÿYesÿ, PuTTY will always pass host names straight to the proxy without trying to look them up first.
If you set this option to ÿAutoÿ (the default), PuTTY will do something it considers appropriate for each type of proxy. Telnet and HTTP proxies will have host names passed straight to them; SOCKS proxies will not.
Note that if you are doing DNS at the proxy, you should make sure that your proxy exclusion settings (see section 4.14.2) do not depend on knowing the IP address of a host. If the name is passed on to the proxy without PuTTY looking it up, it will never know the IP address and cannot check it against your list.
The original SOCKS 4 protocol does not support proxy-side DNS. There is a protocol extension (SOCKS 4A) which does support it, but not all SOCKS 4 servers provide this extension. If you enable proxy DNS and your SOCKS 4 server cannot deal with it, this might be why.
If your proxy requires authentication, you can enter a username and a password in the ÿUsernameÿ and ÿPasswordÿ boxes.
Note that if you save your session, the proxy password will be saved in plain text, so anyone who can access your PuTTY configuration data will be able to discover it.
Authentication is not fully supported for all forms of proxy:
If you are using the Telnet proxy type, the usual command required by the firewall's Telnet server is connect, followed by a host name and a port number. If your proxy needs a different command, you can enter an alternative here.
In this string, you can use \n to represent a new-line, \r to represent a carriage return, \t to represent a tab character, and \x followed by two hex digits to represent any other character. \\ is used to encode the \ character itself.
Also, the special strings %host and %port will be replaced by the host name and port number you want to connect to. The strings %user and %pass will be replaced by the proxy username and password you specify. To get a literal % sign, enter %%.
If the Telnet proxy server prompts for a username and password before commands can be sent, you can use a command such as:
%user\n%pass\nconnect %host %port\n
This will send your username and password as the first two lines to the proxy, followed by a command to connect to the desired host and port. Note that if you do not include the %user or %pass tokens in the Telnet command, then the ÿUsernameÿ and ÿPasswordÿ configuration fields will be ignored.
The Telnet panel allows you to configure options that only apply to Telnet sessions.
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.
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:
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.
If this box is checked, several key sequences will have their normal actions modified:
You probably shouldn't enable this unless you know what you're doing.
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.
The Rlogin panel allows you to configure options that only apply to Rlogin sessions.
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 [email protected], 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).
The SSH panel allows you to configure options that only apply to SSH sessions.
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.
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.
If you tick this box, PuTTY will not attempt to run a shell or command after connecting to the remote server. You might want to use this option if you are only using the SSH connection for port forwarding, and your user account on the server does not have the ability to run a shell.
This feature is only available in SSH protocol version 2 (since the version 1 protocol assumes you will always want to run a shell).
This feature can also be enabled using the -N command-line option; see section 3.7.3.12.
If you use this feature in Plink, you will not be able to terminate the Plink process by any graceful means; the only way to kill it will be by pressing Control-C or sending a kill signal from another program.
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.
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.
If you select ÿ1 onlyÿ or ÿ2 onlyÿ here, PuTTY will only connect if the server you connect to offers the SSH protocol version you have specified.
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.
PuTTY currently supports the following algorithms:
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.
In SSH-2, the encryption algorithm is negotiated independently for each direction of the connection, although PuTTY does not support separate configuration of the preference orders. As a result you may get two warnings similar to the one above, possibly with different encryptions.
Single-DES is not recommended in the SSH 2 draft protocol standards, but one or two server implementations do support it. PuTTY can use single-DES to interoperate with these servers if you enable the ÿEnable legacy use of single-DES in SSH 2ÿ option; by default this is disabled and PuTTY will stick to recommended ciphers.
The Auth panel allows you to configure authentication options for SSH sessions.
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.
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.
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.
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.
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.
This key must be in PuTTY's native format (*.PPK).
The Tunnels panel allows you to configure tunnelling of other connection types through an SSH connection.
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 somewhere unusual, you will need to enter its location in the ÿX display locationÿ box; if this is left blank, PuTTY try to find a sensible default in the environment, or use the primary local display (:0) if that fails.
See section 3.4 for more information about X11 forwarding.
If you are using X11 forwarding, the virtual X server created on the SSH server machine will be protected by authorisation data. This data is invented, and checked, by PuTTY.
The usual authorisation method used for this is called MIT-MAGIC-COOKIE-1. This is a simple password-style protocol: the X client sends some cookie data to the server, and the server checks that it matches the real cookie. The cookie data is sent over an unencrypted X11 connection; so if you allow a client on a third machine to access the virtual X server, then the cookie will be sent in the clear.
PuTTY offers the alternative protocol XDM-AUTHORIZATION-1. This is a cryptographically authenticated protocol: the data sent by the X client is different every time, and it depends on the IP address and port of the client's end of the connection and is also stamped with the current time. So an eavesdropper who captures an XDM-AUTHORIZATION-1 string cannot immediately re-use it for their own X connection.
PuTTY's support for XDM-AUTHORIZATION-1 is a somewhat experimental feature, and may encounter several problems:
XDM-AUTHORIZATION-1, so they will not know what to do with the data PuTTY has provided.
XDM-AUTHORIZATION-1 data.
XDM-AUTHORIZATION-1 data after a session, so that if you then connect to the same server using a client which only does MIT-MAGIC-COOKIE-1 and are allocated the same remote display number, you might find that out-of-date authentication data is still present on your server and your X connections fail.
PuTTY's default is MIT-MAGIC-COOKIE-1. If you change it, you should be sure you know what you're doing.
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:
popserver.example.com:110.
To remove a port forwarding, simply select its details in the list box, and click the ÿRemoveÿ button.
In the ÿSource portÿ box, you can also optionally enter an IP address to listen on, by specifying (for instance) 127.0.0.5:79. See section 3.5 for more information on how this works and its restrictions.
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:
Not all SSH servers work properly. Various existing servers have bugs in them, which can make it impossible for a client to talk to them unless it knows about the bug and works around it.
Since most servers announce their software version number at the beginning of the SSH connection, PuTTY will attempt to detect which bugs it can expect to see in the server and automatically enable workarounds. However, sometimes it will make mistakes; if the server has been deliberately configured to conceal its version number, or if the server is a version which PuTTY's bug database does not know about, then PuTTY will not know what bugs to expect.
The Bugs panel allows you to manually configure the bugs PuTTY expects to see in the server. Each bug can be configured in three states:
An ignore message (SSH_MSG_IGNORE) is a message in the SSH protocol which can be sent from the client to the server, or from the server to the client, at any time. Either side is required to ignore the message whenever it receives it. PuTTY uses ignore messages to hide the password packet in SSH1, so that a listener cannot tell the length of the user's password; it also uses ignore messages for connection keepalives (see section 4.13.5).
If this bug is detected, PuTTY will stop using ignore messages. This means that keepalives will stop working, and PuTTY will have to fall back to a secondary defence against SSH1 password-length eavesdropping. See section 4.20.2. If this bug is enabled when talking to a correct server, the session will succeed, but keepalives will not work and the session might be more vulnerable to eavesdroppers than it could be.
This is an SSH1-specific bug. No known SSH2 server fails to deal with SSH2 ignore messages.
When talking to an SSH1 server which cannot deal with ignore messages (see section 4.20.1), PuTTY will attempt to disguise the length of the user's password by sending additional padding within the password packet. This is technically a violation of the SSH1 specification, and so PuTTY will only do it when it cannot use standards-compliant ignore messages as camouflage. In this sense, for a server to refuse to accept a padded password packet is not really a bug, but it does make life inconvenient if the server can also not handle ignore messages.
If this ÿbugÿ is detected, PuTTY will have no choice but to send the user's password with no form of camouflage, so that an eavesdropping user will be easily able to find out the exact length of the password. If this bug is enabled when talking to a correct server, the session will succeed, but will be more vulnerable to eavesdroppers than it could be.
This is an SSH1-specific bug. SSH2 is secure against this type of attack.
Some SSH1 servers cannot deal with RSA authentication messages at all. If Pageant is running and contains any SSH1 keys, PuTTY will normally automatically try RSA authentication before falling back to passwords, so these servers will crash when they see the RSA attempt.
If this bug is detected, PuTTY will go straight to password authentication. If this bug is enabled when talking to a correct server, the session will succeed, but of course RSA authentication will be impossible.
This is an SSH1-specific bug.
Versions 2.3.0 and below of the SSH server software from ssh.com compute the keys for their HMAC message authentication codes incorrectly. A typical symptom of this problem is that PuTTY dies unexpectedly at the beginning of the session, saying ÿIncorrect MAC received on packetÿ.
If this bug is detected, PuTTY will compute its HMAC keys in the same way as the buggy server, so that communication will still be possible. If this bug is enabled when talking to a correct server, communication will fail.
This is an SSH2-specific bug.
Versions below 2.0.11 of the SSH server software from ssh.com compute the keys for the session encryption incorrectly. This problem can cause various error messages, such as ÿIncoming packet was garbled on decryptionÿ, or possibly even ÿOut of memoryÿ.
If this bug is detected, PuTTY will compute its encryption keys in the same way as the buggy server, so that communication will still be possible. If this bug is enabled when talking to a correct server, communication will fail.
This is an SSH2-specific bug.
Versions below 3.3 of OpenSSH require SSH2 RSA signatures to be padded with zero bytes to the same length as the RSA key modulus. The SSH2 draft specification says that an unpadded signature MUST be accepted, so this is a bug. A typical symptom of this problem is that PuTTY mysteriously fails RSA authentication once in every few hundred attempts, and falls back to passwords.
If this bug is detected, PuTTY will pad its signatures in the way OpenSSH expects. If this bug is enabled when talking to a correct server, it is likely that no damage will be done, since correct servers usually still accept padded signatures because they're used to talking to OpenSSH.
This is an SSH2-specific bug.
We have anecdotal evidence that some SSH servers claim to be able to perform Diffie-Hellman group exchange, but fail to actually do so when PuTTY tries to. If your SSH2 sessions spontaneously close immediately after opening the PuTTY window, it might be worth enabling the workaround for this bug to see if it helps.
We have no hard evidence that any specific version of specific server software reliably demonstrates this bug. Therefore, PuTTY will never assume a server has this bug; if you want the workaround, you need to enable it manually.
This is an SSH2-specific bug.
Versions below 2.3 of OpenSSH require SSH2 public-key authentication to be done slightly differently: the data to be signed by the client contains the session ID formatted in a different way. If public-key authentication mysteriously does not work but the Event Log (see section 3.1.3.1) thinks it has successfully sent a signature, it might be worth enabling the workaround for this bug to see if it helps.
If this bug is detected, PuTTY will sign data in the way OpenSSH expects. If this bug is enabled when talking to a correct server, SSH2 public-key authentication will fail.
This is an SSH2-specific bug.
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 /ea new.reg HKEY_CURRENT_USER\Software\SimonTatham\PuTTY
copy new.reg putty.reg
del new.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.
If you want to provide feedback on this manual or on the PuTTY tools themselves, see the Feedback page.
[$Id: blurb.but,v 1.11.2.2 2004/10/24 22:58:17 jacob Exp $]