SC16IS750 module learning notes

spi_uart_2015sep0401

串口 和 IIC SPI 轉換 SC16IS750 I2C/SPI-to-UART 模塊 ¥44.00

http://world.taobao.com/item/37335150241.htm?fromSite=main&spm=a312a.7700824.w4002-5721859122.11.AOVDjn

这是一个SC16IS750转接板,带IIC总线/SPI接口、64字节发送和接受FIFO和内置IrDA的单UART。SC16IS750是I2C总线/SPI从机总线接口,单通道高性能的UART提供高达5Mbit/s的数据率,低操作和睡眠电流;它还为应用提供8个额外可编程的I/O脚。器件含有极小的24脚HVQFN和TSSOP封装,使其理想适用于便携式和电池操作的应用中。

SC16IS750的内部寄存器集向后兼容广泛使用和普遍流行的16C450。这就使得软件可以容易编写或从另一个平台移植过来。

SC16IS750还提供其它高级的特性,例如自动硬件和软件流控制,自动的RS-485支持和软件复位。这允许软件可在任何时候复位UART,与硬件的复位信号无关。

应用

制造自动化和进程控制

便携式和电池操作的设备

单元数据设备

.END

Leave a comment

Filed under Uncategorised

0:0和中國續居榜首 – 蘋果日報

kilama_2015sep0301

0:0和中國續居榜首 咖喱:戰術成功 門柱保佑 – 蘋果日報 2015年09月03日

http://hk.apple.nextmedia.com/realtime/sports/20150903/54164553

港隊賽前揚言,要踢三防中,打鐵桶陣,堵塞國足在中路的組織。教練金判坤最終派出黃洋、白鶴兩名搶截能手,配搭長傳出色的林嘉緯,穩守中場中路,梁振邦在負責在右路協助右閘積施利防守,左邊就靠高梵及李志豪,隊長陳偉豪夥拍法圖斯踢中堅,葉鴻輝則把守最後一關,而速度快的麥基就踢最前。港足的應戰策略正確,國足為了避免跟港隊的中路鐵桶陣硬碰,上半場主要靠兩翼及遠射製造威脅。

雖然港隊隊長陳偉豪一開波就受傷,在五分鐘退下火線,由基藍馬入替,但沒有破壞到港隊的防守體系。國足的高波傳中戰術對港隊的威脅甚微,很多時被基藍馬及法圖斯這對非裔中堅清走,或者被葉鴻輝沒收。比較港隊兩閘,積施利今場位置感非常好,加上梁振邦十分勤力,所以港隊右路防守較穩固,國足左閘姜至鵬基本上沒有威脅。相反,港隊左閘李志豪失誤較多,中國右閘「張莫斯」張琳芃頻頻助攻,壓落底線出波。及後,高梵加強回防,協助李志豪頂住張琳芃。

國足最有威脅的攻勢一是來自少有成功的中路入楔,二是遠射,但港隊靠血肉長牆加上門柱及門楣的幫助,頑強抵抗。國足最有級數的球員始終是鄭智,他經常墮後至防線之前分波,但當他間中上前參與組織時,往往能夠製造到最具威脅的攻勢,10分鐘,基藍馬解圍,鄭智截到,施展遠射,葉鴻輝僅僅救到再中柱。一分鐘後,他妙傳于漢超,後者單刀埋門,基藍馬「瞓身」護空門,皮球再中柱出界。36分鐘,于漢超再次中柱。44分鐘,又是鄭智的遠射,結果中楣。

換邊後,港隊越踢越有信心,基藍馬領導防線的能力亦不在陳偉豪之下,加上國足基本上放棄中路入楔,沉迷於兩翼傳中,正中香港下懷。國足的前鋒越踢越心急,把握力比上半場更差,最終香港靠適當的戰術及全軍將士用命之下,加上一點運氣,13年來首次對中國不敗。香港下場對卡塔爾繼續努力!

文:咖喱
【戰果速遞】

香港代表隊在2018年俄羅斯世界盃亞洲區第二輪外圍賽C組賽事作客中國,儘管港足在全場比賽皆受制於主隊,但在一眾港將負隅頑抗拼命死守下,卒成功以0:0守和世界排名比自己高67位的中國隊,13年內首次賽和國足。兩隊各得1分後,港足以三戰得7分繼續排在C組榜首。

港足今仗在開賽初段即有隊長陳偉豪在一次解圍中受傷,這位效力港超聯南華的中堅更未能繼續比賽,逼得港隊在開賽只有4分鐘即先動用第一個換人名額,港隊主帥金判坤安排基藍馬入替陳偉豪。比賽繼續後,主隊有隊長鄭智的遠射中柱彈出;至12分鐘,國足的于漢超突破越位陷阱再推過港隊門將葉鴻輝後起腳射空門,但及時回防的基藍馬在白界線前將皮球截住,皮球之後再彈中右邊柱外側,港隊力保不失。

完全主導比賽形勢的中國隊,之後繼續強攻港隊。28分鐘,吳曦在禁區內起腳施射,被及時出迎封位的葉鴻輝擋出,皮球彈高後,武磊頭槌攻門頂向空門,再一次被基藍馬成功護駕。36分鐘,中國隊的于漢超接應隊長靚絕的長傳,在禁區內無人看管的情況下施展臥射,皮球再度中柱彈出。44分鐘,鄭智在禁區外燙射又告中楣,門框在上半場四次守護住港隊的大門。

易邊後,中國隊繼續主導形勢。54分鐘,武磊在禁區邊峨嵋月頂起腳扣關,但港隊守門員葉鴻輝反手將皮球撲出底線。中國隊其後接連作出三個調動,先後以王永珀、楊旭和孫可入替吳曦、鄭龍和于漢超,力圖撕破港隊防線。71分鐘,演出神勇的葉鴻輝再次施展神級撲救,將任航的頭槌撲出底線。79分鐘,港隊得到稀有的進攻機會,可惜麥基在禁區內的熨射高出。香港隊之後全軍退守,後備入替的前鋒陳肇麒在比賽末段於禁區內犯手球,幸球證未有判罰,最終港足在不被看好的情況下,成功守和中國,在世盃外取得寶貴的1分。

.END


SPI-to-UART Breakout – SC16IS750

串口 SPI 轉換 SC16IS750

.END2

Leave a comment

Filed under Uncategorised

Philips 21.5″ LED monitor comoparsion

PHILIPS 227E4LHAB Full HD 21.5″ LED Monitor

Screen technology LED backlit
Screen size 21.5″
Resolution 1920 x 1080
Brightness 250 cd/m²
Response time 2 ms
Native contrast ratio 1000:1
Dynamic contrast ratio 20000000:1

AUDIO
Speakers 2
Audio power 4 W
Mono / Stereo sound Stereo

CONNECTIVITY
– HDMI x 1
– VGA x 1


http://www.price.com.hk/category.php?c=100024&brand=Philips&filter=100309,100681,100314&page=1

http://www.price.com.hk/product.php?p=155191

Philips 227E4QHAD HK$1098
(22″ IPS)
8.0
屏幕尺寸: 21.5吋
LED背光: IPS
解像度: 1920 x 1080
對比度: 20,000,000:1
亮度: 250cd/㎡
反應時間: 7ms
介面: HDMI, D-sub
內置喇叭: 是
Philips 227E3QPHSU HK$1099
未有任何評分
屏幕尺寸: 21.5吋
LED背光: W-LED
解像度: 1920 x 1080
對比度: 20000000:1
反應時間: 14ms
介面: DVI / VGA / HDMI
內置喇叭: 有
Philips 227E3LHSU HK$1080
8.6
屏幕尺寸: 22吋
LED背光: 是
解像度: 1920 x 1080
對比度: 20000000:1
亮度: 250cd/㎡
介面: D-Sub, DVI, HDMI
內置喇叭: 是
Philips 227E3LH HK$1090
(HDMI,DVI,VGA,1920X1080)
8.6
屏幕尺寸: 22吋
LED背光: 是
解像度: 1920 x 1080
對比度: 20000000:1
反應時間: 2ms
介面: HDMI / DVI / VGA
內置喇叭: 是

.END


飛利浦 E 系列, 21.5 吋 227E4LHAB/69

.END

Leave a comment

Filed under Uncategorised

Acer G227HQL HK$1,198

Acer G227HQL $ 1198

最大解像度 1920 x 1080

HDMI VGA

6 ms

250 cd/m²


G7

型號名稱 : G227HQL
部件號碼 : UM.WG7CF.001
$ 1198

熱門比拼
HDMI VGA
6 ms
250 cd/m²

查看完整數據表

關閉G227HQLUM.WG7CF.001
技術資訊
螢幕數 1
螢幕尺寸 54.6 cm (21.5″)
螢幕解析度型式 Full HD
反應時間 6 ms
螢幕比例 16:9
水平視角 178°
垂直視角 178°
背光技術 LED
面板技術 橫向電場效應顯示 (IPS) 技術
功能 CrystalBrite
可調整角度 有
傾斜角度 -5°至15°
旋轉角度 否
可調校顯示高度 否
可調校顯示支點 否
視像
最大解像度 1920 x 1080
支援色彩 16.7百萬色彩
對比率 100,000,000:1
亮度 250 cd/m²
介面/連接埠
HDMI 有
VGA 有
功率說明
輸入電壓 110 V AC
220 V AC
開機耗電量 25 W
待機耗電量 490 mW
關機耗電量 450 mW
實體特性
色彩 黑色
含腳架高度 384 mm
含腳架寬度 499 mm
含腳架厚度 185 mm
其他
包裝內容
G227HQL LCD闊屏幕
加長電線
1 x VGA接駁線
環保認證 MPR II
保固
保固

.END

Leave a comment

Filed under Uncategorised

tightvnc server viewer testing notes

vnc_test_2015sep0301

tightvnc server viewer testing notes

.END

Leave a comment

Filed under Uncategorised

等一個人閱兵 – Mayi

回顧、反省,也是祝福-寫在香港九月三日一次性的假期 – Mayi 主場博客 2015sep03

這篇文在我腦海裡已存在一段很久的時間。總不能只談風花雪月,卻不談歷史。當然我寫的都不是大論述,而是我第一身與日本人接觸時所知道的他們對二戰抱什麼感覺,還有一些自己整合後的想法。他們是否不面對歷史?他們是否死不悔改?一次性假期,也就一次性登出。既然不是風月,所以內容有點長,像阿婆紮腳布,先謝過各位的耐性。

剛到日本留學時,我也會問一些相熟的日本朋友怎樣看二戰侵華這段歷史?為何只簽降書卻不道歉?說實的,我因為這問題而失去了很多日本朋友,

也有日本朋友願意輕省回答一句:「這已不是我們這一代的事了。我只可肯定的告訴你,日本不會再發動任何戰爭。」

留學那年的暑假,我在鹿兒島知覽的農家種茶,也就和接待我的一家人相熟了。不用種茶時,兩位嬸嬸帶我到知覽市內遊覽。知覽,是當年神風突擊隊的基地,基地遺址現在是博物館,展出當時隊員的照片、名冊、遺物、遺書和當時那些只為直衝美國軍艦沒有逃生設備的戰機等。當時,一張張十七八歲的面孔再配上他們手寫的遺書,離開博物館時我的淚根本不能止,兩位嬸嬸也一起哭:「真的,我們真的不要再打仗了,打仗太慘了。」後來才知,嬸嬸的家族也有些叔伯在戰爭死了,還是英年。可是,我同時也生氣自己為什麼要哭:「日本在戰爭時是敵人,有什麼好哭!」

十年後,嬸嬸的老公再帶我和女兒到同一個博物館。那時我已有心理準備會在博物館見到什麼,我也不再哭。嬸嬸的老公說:「你嫁來日本了,你是我們一份子了,你要了解日本的想法。」我問:「是什麼想法?」他是一個十分疼我的伯伯,他猶疑了一回,就直說:「其實我還是不喜歡中國的,可是我們也不會再發動戰爭,因為戰爭也把我們搞得很慘。」我聽他這樣說時,心裡很生氣,你們發動的戰爭把你們搞得很慘,難道被搞的中國不慘?再加上之後的內戰,結果連政權都要更替,共產黨還謝過日本侵華,中國受的苦到今天還在承受中。

可是後來,我明白到伯伯所言的「慘」,真實所指的不只是戰爭是死去的人或原爆。我在東京時,常常幫襯一家蛋糕店,老闆是留法十年學整餅的蛋糕師傅,思想十分開放,很西化,是我的偶像。當時的場景是這樣的:店內一角的電視正播放終戰紀念日的特輯,都是彈些老調說戰爭禍害深、希望日本和世界都和平之類。他在收銀台看著電視螢幕,冷冷地說了一句:「昭和應該切腹謝罪吧。」我以為自己聽錯,望一望他,他再說:「對,我說,昭和應該切腹,為戰爭、為國家謝罪。」日本到今日還有皇室的,他們傳媒雖有言論自由,可是不利皇室的醜聞還是不可以報道的;而在報章上報道皇室新聞,必須用尊稱和敬語。所以我不太相信老闆會說這樣在日本國內也大不敬的話。

老闆說:「我知道你是中國人,所以更加要向你說清楚我的想法。中國常常覺得日本死不認錯,不為戰爭道歉。

1945年之前的日本軍隊全都叫皇軍,他們是天皇的軍隊,沒有天皇的印鑑根本不能出兵。

當時的天皇是誰?昭和。天真到真的會被首相和其他將軍左右出兵,你信嗎?

在戰場上死的人,可是皇軍,可是為你-昭和而死。

戰敗後,就把所有責任推卸給甲級戰犯,不正式道歉、自己繼續當天皇、頤養天年。

對日本公平嗎?對在你名下出征而客死異鄉的人,公平嗎?」

「外國常常以德國和日本比較說,德國多好,願意認錯、道歉、承擔戰爭責任;日本呢?正正相反,死不悔改、不正視歷史、不承擔責任。

可是日本正正是一個最喜歡凡事都すみません(Sumimasen)、ごめんなさい(Gomennasai)的民族,不是嗎?為什麼有戰爭不能面對呢?

因為我們日本人,最少我和上一代知道,最應該承擔責任的人和最能代表日本道歉的人,不願意道歉。我們不能像德國人把戰爭推到納粹和希特拉身上,永久的摒棄他們,然後整個國家民族重新出發;我們日本不可以,天皇還在,他的兒子和孫兒也會繼續做天皇,日本可以做的就是承諾不會再發動戰爭,然而我們永遠都不能堂堂正正地面對歷史了。由昭和死的那天,大和民族承擔責任的機會就已經錯失了。

最近有一套電影叫《日本最長的一天》,劇情就是描述裕仁天皇要宣告無條件投降了,可是有些好戰的陸軍不甘心而去阻止之類。

實際上裕仁是否真的如此甘心、服輸、愛民如子呢?日本宮內廳在1/8/2015將當年昭和天皇宣佈結束戰爭的「玉音廣播」原始錄音唱片及音頻,首度公開。

裕仁刻意以文言日文宣讀,當時一般日本民眾驟耳聽其實聽不懂他在說投降;還有,他選擇「終戰」(しゅうせん/Syūsen)而不用「投降」(とうこう/toukou)。見微知著,可知他本人也真是死不悔改卻只是迫於無奈而投降。

我不同意蛋糕店老闆說的全部,就算裕仁是一個不悔改的戰犯也無礙日本為二戰道歉。

因為日本仍有天皇,在位的明仁其實可為他父輩道歉,好讓中國、韓國、其他侵略過的東南亞國家也得公道。後來我讀到一本 Herbert P. Bix 的著作 Hirohito and the Making of Modern Japan,中譯本書名叫《裕仁天皇與近代日本的形成》讓我那個「父債子還」的希望也落空了。這本書還拿了2001年普立茲獎(非小說部)。作者 Herbert P. Bix 是美國的歷史學者、大學教授,

他筆下的裕仁絕非無辜善類,而是有份策劃、積極參與二戰的戰犯

書裡有一頁記述了裕仁天皇死後,明仁登位。記者會中有記者問明仁:「天皇陛下,你會為二戰道歉嗎?」當時明仁答:「這已經不是我們這一代的事了。」自此,沒有日本記者再問同一個問題,因為他們都知道,他們只會得到一樣的答案。

那我們可以等的,就是下一任天皇繼承時,再問他同一個問題嗎?可是我相信就算下一任天皇,下下一任天皇,似乎都會繼承現任天皇的路線-就是「走數,然後希望歷史遺忘、淡化、反正幾百年後天皇制度還在,可是會介意日本有沒有道歉的人,都死了好幾輩了。

雖然天皇還未/不道歉,而新華社在幾天前還咬著不放這個問題。可是日本的政府和民間呢?他們有沒有為戰爭道歉?答案是肯定的。我不細數歷來道歉過的日本首相,只著眼最近的安倍和他在剛剛八月十四日為戰敗七十年發表的「内閣総理大臣談話」,我節錄其中三段:

「戦後七十年にあたり、国内外に斃れたすべての人々の命の前に、深く頭を垂れ、痛惜の念を表すとともに、永劫の、哀悼の誠を捧げます。」

(官方中譯:正當戰後七十周年之際,我在國內外所有死遇者面前,深深地鞠躬,並表示痛惜,表達永久的哀悼之意。)

……

「戦火を交えた国々でも、将来ある若者たちの命が、数知れず失われました。中国、東南アジア、太平洋の島々など、戦場となった地域では、戦闘のみならず、食糧難などにより、多くの無辜の民が苦しみ、犠牲となりました。戦場の陰には、深く名誉と尊厳を傷つけられた女性たちがいたことも、忘れてはなりません。

(官方中譯:同樣,在與日本兵戎相見的國家中,不計其數的年輕人失去了原本有著未來的生命。在中國、東南亞、太平洋島嶼等成為戰場的地區,不僅由於戰鬥,還由於糧食不足等原因,許多無辜的平民受苦和遇難。我們也不能忘記,在戰場背後被嚴重傷害名譽與尊嚴的女性們的存在。)

何の罪もない人々に、計り知れない損害と苦痛を、我が国が与えた事実。歴史とは実に取り返しのつかない、苛烈なものです。一人ひとりに、それぞれの人生があり、夢があり、愛する家族があった。この当然の事実をかみしめる時、今なお、言葉を失い、ただただ、断腸の念を禁じ得ません。」

(官方中譯:我國給無辜的人們帶來了不可估量的損害和痛苦。歷史真是無法取消的、殘酷的。每一個人都有各自的人生、夢想、所愛的家人。我在沉思這樣一個明顯的事實時,至今我仍然無法言語,不禁斷腸。)

我的母語不是日語,可是安倍的用字其實不如我們新聞所報道的「沒有誠意」。深く頭を垂れ/痛惜の念を表す/永劫の、哀悼の誠を捧げます/断腸の念を禁じ得ません……等等,都已經是日語中深層次的歉意表達了當然,安倍如果能像鳩山由紀夫一樣行禮會更好。12/8/2015,日本的前首相鳩山由紀夫訪問南韓期間,在首爾紀念南韓抗日人士的紀念碑前行跪拜禮謝罪。(參13/8/2015無綫新聞報道-鳩山由紀夫南韓下跪謝罪 促日政府道歉)

日本民間也有企業作出正式道歉。日本三菱集團旗下公司向二次大戰時強逼美國戰俘做苦工道歉,是七十年來首次。三菱綜合材料常務執行役員木村光表示:「今天,很感謝有這場會面,在此我要致以最誠懇的道歉,向當年的美國戰俘墨菲及其他所有美國戰俘,他們被強徵到三菱前身的礦場做苦工,並向其家人(道歉)。」(引述自20/7/2015無綫新聞報道-三菱首次向二戰被勞役美國戰俘道歉)這是一個很好的開始,我希望之後陸續有其他日本企業願意效法。

我贊成

村上春樹提出的做法:「(日本)要一直道歉,直到(曾被日本侵略的)這些國家說:『我們無法完全忘記過去,但你的道歉足夠了。我們讓它過去吧』。」

(引述台灣蘋果日報18/4/2015報道-村上春樹︰日本要一直道歉 直到受害國說「足夠」為止)

剛過的星期日(30/8/2015),日本全國各地爆發反安保法案及要求首相安倍晉三下台的示威,主辦單位聲稱有多達一百萬人參加。單單在首都東京已有十二萬人包圍國會,是至今規模最大的日本反政府集會。日本人反安保法案的主因是擔心自衛隊的集體自衛權獲承認後,自衛隊的活動範圍會擴大、可用武器增多、武器使用基準放鬆等等,一言蔽之就是放寬軍權,日本可能再陷戰爭,最差的情況是重蹈二戰侵華的覆轍。

所以很多不習慣上街遊行示威叫喊的日本人都上街了。由此可見,日本真是如我們在黨媒報道所見的日本一樣,死不悔改、不承認歷史、篡改教科書、右翼主義高漲、軍國主義隨時復辟的日本嗎?

一個把歷史竄改,硬把自己說成「中流砥柱」的政權,

今天高調地上演「等一個人閱兵」。

又,一個建國只有六十六年的國家喜孜孜地慶祝一場七十年前已完結的戰爭。一邊無視自己的罪孽,一邊竄改歷史,一邊大聲疾呼要求戰敗國的天皇道歉。

自己都未正視歷史,又有什麼資格去要求人正視歷史呢?

昨日,在巴士站等兒子放學時,一眾日本媽媽在討論明天放假,突然一個日本媽媽多口問:「為什麼突然多了一天假期?」之後一眾日本媽媽顧左右而言他,氣氛尷尬。那時我心想:「難道要明言:『係呀,香港放假因為慶祝日本戰敗七十週年』嗎?」

最後,真心祝福日本這個民族終有一日天皇能正式道歉,早日能帶領整個民族坦蕩蕩的面對歷史,像德國一樣重新出發-雖然,已經遲了最少七十年。

.END

Leave a comment

Filed under Uncategorised

The question is, does the Pi really need Windows? – Tim Anderson

A good effort, if a bit odd: Windows 10 IoT Core on Raspberry Pi 2 The question is, does the Pi really need Windows? – Tim Anderson 21 May 2015

http://www.theregister.co.uk/2015/05/21/first_look_windows_10_iot_core_on_raspberry_pi_2/?page=2

First Look

Microsoft has released a preview of Windows 10 for Raspberry Pi 2, the £30 ARMv7 computer board produced by the Cambridge-based Raspberry Pi Foundation.

The version of Windows 10 for the Pi (which is also available for the Intel Atom MinnowBoard Max) is called Windows IoT Core, one of three Windows 10 IoT editions. The other two are Windows 10 IoT for mobile devices (which is ARM only and similar to Windows 10 Mobile) and Windows 10 IoT for industry devices, which is Intel only and similar to Windows 10 Enterprise, tweaked to run a single locked-down application such as for a cash or vending machine.

In other words, the company has hijacked the IoT (Internet of Things) buzzword and applied it to embedded Windows. That said, the old Windows CE apparently lives on for those who need it, since unlike other versions of Windows it is a real-time operating system (RTOS).

Windows 10 IoT Core is an oddity in that while it does have a GUI stack, it is limited to Microsoft’s Universal App Platform (UAP), though note that this includes DirectX as well as XAML (Microsoft’s presentation language for UAP) and HTML.

This means that there is no Windows desktop, nor even a command prompt.

That said, it does support PowerShell remoting, which gets you a remote PowerShell terminal from which you can run familiar Windows commands.

Although education and hobbyists seems to be the main target markets for Windows 10 IoT Core on the Pi, there are also features aimed at business users, though it is not clear whether these are in the preview.

Devices running the OS will be manageable via InTune (a cloud service) or System Center, and you will be able to configure updates in one of three modes: all features, security patches only or none. Domain join is not possible, though.

The price? “Windows 10 will include a new IoT edition for small devices that is tuned to run Windows universal apps and drivers and is royalty free to makers and device builders,” said Microsoft’s Don Box in this post.

Note that IoT Core is not limited to UAP apps. Native Win32 apps run, but you will not see any output other than in a remote session. You can create server apps, though, and one of the samples uses Node.js with a native extension to return memory status to a browser. There is no web server in IoT Core, but Node.js has one built-in. Node.js normally uses the Chrome JavaScript runtime, but in this case it uses Microsoft’s Chakra engine instead.

The current preview has several limitations.

Wi-Fi and Bluetooth are not supported,

and there is a long list of other issues which make the preview suitable for experimentation only.

In addition, not all UAP APIs are supported.

Getting Started

Setting up Windows 10 IoT Core on a Pi 2 is a matter of signing up to Microsoft’s preview programme, downloading an SD card image and writing it to a card using Windows 10 technical preview.

The documentation says you need a physical Windows 10 machine in order to get access to a card reader, but apparently VMWare can also work.

Next, you pop the card into your Pi, preferably with an HDMI display attached, and boot up. You can also connect a USB keyboard and mouse. It takes a while to boot – especially the first time, when some set-up tasks run – but it worked first time for me, displaying a screen of information including the device name and IP address.

Doing anything with the Pi requires a remote connection. I was able to connect via PowerShell, change the password and deploy a HelloWorld UAP app from Visual Studio 2015 running on Windows 10 build 10074. Everything worked first time. File sharing is on by default and I was able to browse the file system from another PC using the built-in administrative shares C$ and D$.

The overall size of Windows IoT Core is similar to the stripped-down Nano Server, which we looked at here. It is a crude measure, but the Windows folder on the Pi contains 809MB in 3,356 files, whereas on Nano it is 946MB and 9,194 files.

I opened a not-entirely-trivial Windows Store game app project (a work in progress) in Visual Studio and tried running that on the Pi. Again, it worked first time, even though it is not strictly a UAP app. Performance was not great, but it was playable.

Visual Studio’s remote debugger works well with the Pi, giving you breakpoints, variable inspection and so on, but there is no virtual machine option so you have to exercise your app on the Pi itself.

If the app also runs on a PC you can test it there, which is more convenient,

but as soon as you need to interact with the Pi’s GPIO (general purpose input/output pins) or other Pi-specific hardware, this will not work.

A built-in web application on the Pi lets you monitor and manage the device. This is rather good and includes the ability to list, install, start and stop UAP apps, see running processes, check CPU, I/O and memory usage, download kernel dumps for debugging, check network configuration and more.

Efforts to run Python apps on the Pi failed initially, but a browse through the forums revealed a registry key you can set to overcome an incompatibility with some SD cards. Once added,

Python apps worked, using Microsoft’s Python UAP SDK.

An ideal scenario is where you have developed an app which you want to run automatically on start-up. A tool called IotStartup lets you specify the app to run, using PowerShell.

Does the Raspberry Pi need Windows?

It already runs several varieties of Linux, including Raspbian (based on Debian), Ubuntu and Fedora. These distributions lack the peculiarities of Windows IoT Core, with full access to the local command shell, as well as a desktop GUI should you need it. You can even run .NET applications using Mono and it should support the cross-platform .NET Core as well.

So what is the point of Windows?

Putting Windows 10 IoT Core on a Pi makes it less capable than it would be running Linux,

but there will still be cases where it makes sense. In an educational context, where you want a smooth workflow for developing an app in Visual Studio, and testing and deploying on the Pi, it could work well.

Visual Studio is a rich IDE, and with support for C#, Visual Basic, Python, Node.js and C++, there is plenty of scope for language experimentation. This does imply Windows desktops in the classroom, and of course the promotion of Windows and its new Universal App Platform is Microsoft’s incentive for investing in the Pi community.

Microsoft’s strategic goals may explain why IoT Core lacks a command shell or Windows desktop, both of which would be welcome among Pi users attempting to use it like a PC. The software giant is trying to drive developers towards UAP.

There is value here for Microsoft platform developers developing apps that will integrate with Windows server applications and device management.

These are special cases, though. Playing with the technical preview is a lot of fun if you are familiar with Visual Studio and Windows, but do not expect Linux to be displaced from the Pi mainstream any time soon.

.END

Leave a comment

Filed under Uncategorised

教會單身盛女現象的形成 – 殷琦

事奉疲勞 – 殷琦 輔仁媒體 2015年9月2日

幾十歲人唔好咁多幻想

「為教會做義工」,小至參加派月餅、探訪、大至做團契職員、導師,到進入教會「政體」,參與行政、決策,大至做執事、做終身執事、統統都是「事奉」的一種,總之就是無償地「為教會做義工」「乜野呀,天上的財寶咪等緊你囉!」傳道人插咀)。

耶教事奉之風甚盛,其實已存在不少問題,在這裡先談「事奉疲勞」。

「事奉疲勞」?顧名思義,就是做事奉做到 burn out 無哂奶。有時看戲3D太長太勁,會做成「視覺疲勞」;做事奉做得太多、為做而做、日復日年復年做、不知其所以然,視為「事奉疲勞」。曾有弟兄分享過一個理論:在一個工作環境中,大概只有30%的人是做事,60%的人在hea;那還有10%的人,就是在把60%的人的工作,再繼續分配給那30%的人做。

教會,也正正如此

不少人返教會,先先當然是來 take,參加活動、給給意見當然容易,

做新朋友(教會一般對新來賓的統稱)當然接受許多的關心和愛

但時間一久、某些人在獲邀做事奉,進一步為教會付出時,就顯得不甚願意。

是的,做被關心當然比較容易了吧?那誰去做關心人的人呢?

漸漸地、有些熱心的、願意付出的「多功能恩賜千手觀音萬能俠」信徒,就一星期做四、五日事奉,什麼星期一練詩、星期二開團契會、星期三祈禱會帶詩、星期五開委辦會、星期六做青少年事奉、星期日做司事…

筆者都曾經是「教會是我家(清潔齊參加?)」的信徒之一,每天為教會事奉疲於奔命,見教會還比起見家人的時間還多,以致終有一天你會問自己:其實我起度做緊乜 呢?

教會單身盛女現象的形成,與事奉太多變相限制個人生活圈子,兩者亦是互為因果吧。

另外,教會另一扭曲事奉的怪象,就是離地萬丈地認為教會應該是生命中的唯一。

筆者曾聽過不止一次,如果工作時間與祟拜或者事奉相撞,傳道人的口吻往往是「唔唔,事奉同工作的抉擇,其實答案都好明顯呀」,似乎應該是要高唱「(王力宏:唯一)事奉~妳就是我的唯一 兩個世界都變形~」才是合乎神心意,所以需要星期六、日上班的工作一律不乎上帝心意,而且如果夾到多幾次能回到教會,就要講「感謝主啊~~」。

其實世界上有不少工種是星期六、日開工(如筆者便是一例)、傳道人自己也是啊,何以又會對信徒有如此這般的要求呢?

此外,所謂「事奉」有時亦涉及一些專業知識,例如會計、設計師、音樂人等,就常常被教會拿「事奉」二字開刀,以致連提出「其實呢,應該是要收費的」幾隻字都不敢,因為這絕對是會被認為「事奉點會講錢呢?」(咁傳道人呢?)。

筆者聽過不下幾次有設計師要免費幫教會設計會章、編書排版而不收分毫,而身為音樂人的筆者亦是以往多次在不同場合無償地為教會做需要專業水準才做得來的音樂事工(其實話時話教會又好意思叫人做,真是面皮幾呎厚,此等風氣實在令人氣結)。其實都是果句,做藝術都要開飯的,你估人家是二世祖唔使做才做藝術嗎?教會又是用甚麼眼光去看待這些專業?So sorry,一切是理。所。當。然。會真正真金白銀付出與工量同等的教會實在是鳳毛麟角,久而久之,專業人也會做到好灰而 burn out,真是走左都唔知咩事

最後,請唔好講「你應該越事奉越喜樂架,如果你唔是,咁就應該是因為無祈禱無讀經唔親近神 blablabla…」。

請一些人不要以如斯涼薄的態度去對待這些已經事奉疲勞的肢體。會做到事奉疲勞的,往往就是原本最有心、最願意付出的一群。一句撻埋黎,教會、在上者一丁點需要反思的空間也沒有?

而事奉疲勞的肢體們,也真實面對自己吧:累就是累、chur 就是 chur、做到無時間無精力與神親近就是了,又有什麼好掩飾?基督徒就是太多事要無原因地正能樣,明明就是唔開心到一個點,最後分享都總要兜個尾彩,講句「但是即使咁辛苦我都覺得上帝同我同在!」、「上帝會加力俾我既!」,誰知最後捱不住崩潰的正正就是自己。多就退一點、覺得無理就不要理(別盲目信服掌權者吧);

過多的事奉對靈命也不甚健康,如真的有心至此,也大概要到委身服待的階段罷,自己不妨好好祈禱。

在如斯嚴峻的情況下都「越事奉越喜樂」的,一是就是得閒到暈低的家庭主婦;一是就是事奉事到變耶能的人,才不會事奉疲勞了吧。

服待神啫,點解會搞到自己咁樣呢。

.END

Leave a comment

Filed under Uncategorised

Protected: 序章 三体2 黑暗森林 刘慈欣

This content is password protected. To view it please enter your password below:

Enter your password to view comments.

Filed under Uncategorised

puTTY learning notes

putty User Guide Summary

Chapter 2: Getting started with PuTTY

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

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 `Connection type’
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 (see
section 3.6). The fifth option, Serial, is used for connecting to
a local serial line, and works somewhat differently: see section 3.7
for more information on this.

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 theOpen’ button
at the bottom of the dialog box, and PuTTY will begin trying to
connect you to the server.

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 rsa2 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.)

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; many SSH servers do not permit 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.

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.

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' orexit’, 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.

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.

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.11.2). (Pressing Shift-Ins, or selecting `Paste’ from
the Ctrl+right-click context menu, have the same effect.) 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.11.5.)

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.11.4 for details.

(In some Unix environments, Alt+drag is intercepted by the window
manager. Shift+Alt+drag should work for rectangular selection as
well, so you could try that instead.)

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.

It’s possible for the server to ask to handle mouse clicks in the
PuTTY window itself. If this happens, the mouse pointer will turn
into an arrow, and using the mouse to copy and paste will only work
if you hold down Shift. See section 4.6.2 and section 4.11.3 for
details of this feature and how to configure it.

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. You can scroll
a line at a time using Ctrl-PgUp and Ctrl-PgDn. These are still
available if you configure the scrollbar to be invisible.

By default the last 2000 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.7.3.

3.1.3 The System menu

If you click the left mouse button on the icon in the top left
corner of PuTTY’s terminal 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.

(These options are also available in a context menu brought up by
holding Ctrl and clicking with the right mouse button anywhere in
the PuTTY window.)

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.

3.1.3.2 Special commands

Depending on the protocol used for the current session, there may
be a submenu of special commands'. These are protocol-specific
tokens, such as a
break’ signal, that can be sent down a connection
in addition to normal data. Their precise effect is usually up to
the server. Currently only Telnet, SSH, and serial connections have
special commands.

The `break’ signal can also be invoked from the keyboard with Ctrl-
Break.

The following special commands are available in Telnet:

  • Are You There
  • Break

  • Synch

  • Erase Character

PuTTY can also be configured to send this when the Backspace key
is pressed; see section 4.16.3.

  • Erase Line
  • Go Ahead

  • No Operation

  • Should have no effect.

    • Abort Process
  • Abort Output

  • Interrupt Process

  • PuTTY can also be configured to send this when Ctrl-C is typed;
    see section 4.16.3.

    • Suspend Process

    PuTTY can also be configured to send this when Ctrl-Z is typed;
    see section 4.16.3.

    • End Of Record
  • End Of File

  • In an SSH connection, the following special commands are available:

    • IGNORE message

    Should have no effect.

    • Repeat key exchange

    Only available in SSH-2. Forces a repeat key exchange
    immediately (and resets associated timers and counters). For
    more information about repeat key exchanges, see section 4.19.2.

    • Break

    Only available in SSH-2, and only during a session. Optional
    extension; may not be supported by server. PuTTY requests the
    server’s default break length.

    • Signals (SIGINT, SIGTERM etc)

    Only available in SSH-2, and only during a session. Sends
    various POSIX signals. Not honoured by all servers.

    With a serial connection, the only available special command is
    `Break’.

    3.1.3.3 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 in a new
    window 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.

  • In an inactive window, selecting Restart Session' will do the
    same as
    Duplicate Session’, but in the current window.

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

  • 3.1.3.4 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).

    You can save the current settings to a saved session for future use
    from this dialog box. See section 4.1.2 for more on saved sessions.

    3.1.3.5 Copy All to Clipboard

    This system menu option provides a convenient way to copy the whole
    contents of the terminal screen (up to the last nonempty line) and
    scrollback to the clipboard in one go.

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

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

    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.

    3.3 Altering your character set configuration

    If you find that special characters (accented characters, for
    example, or line-drawing characters) 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 theTranslation’ panel,
    you should see a large number of character sets which you can
    select, and other related options. Now all you need is to find out
    which of them you want! (See section 4.10 for more information.)

    3.4 Using X11 forwarding in SSH

    3.6 Making raw TCP connections

    3.7 Connecting to a local serial line

    PuTTY can connect directly to a local serial line as an alternative
    to making a network connection. In this mode, text typed into the
    PuTTY window will be sent straight out of your computer’s serial
    port, and data received through that port will be displayed in the
    PuTTY window. You might use this mode, for example, if your serial
    port is connected to another computer which has a serial connection.

    To make a connection of this type, simply select Serial' from theConnection type’ radio buttons on the Session' configuration panel
    (see section 4.1.1). The
    Host Name’ and Port' boxes will transform
    into
    Serial line’ and Speed', allowing you to specify which serial
    line to use (if your computer has more than one) and what speed
    (baud rate) to use when transferring data. For further configuration
    options (data bits, stop bits, parity, flow control), you can use
    the
    Serial’ configuration panel (see section 4.27).

    After you start up PuTTY in serial mode, you might find that you
    have to make the first move, by sending some data out of the serial
    line in order to notify the device at the other end that someone is
    there for it to talk to. This probably depends on the device. If you
    start up a PuTTY serial session and nothing appears in the window,
    try pressing Return a few times and see if that helps.

    A serial line provides no well defined means for one end of the
    connection to notify the other that the connection is finished.
    Therefore, PuTTY in serial mode will remain connected until you
    close the window using the close button.

    3.8 The PuTTY command line

    PuTTY can be made to do various things without user intervention
    by supplying command-line arguments (e.g., from a command prompt
    window, or a Windows shortcut).

    3.8.1 Starting a session from the command line

    These options allow you to bypass the configuration window and
    launch straight into a session.

    To start a connection to a server called `host’:

    putty.exe [-ssh | -telnet | -rlogin | -raw] [user@]host

    If this syntax is used, settings are taken from the Default Settings
    (see section 4.1.2); `user’ overrides these settings if supplied.
    Also, you can specify a protocol, which will override the default
    protocol (see section 3.8.3.2).

    For telnet sessions, the following alternative syntax is supported
    (this makes PuTTY suitable for use as a URL handler for telnet URLs
    in web browsers):

    putty.exe telnet://host[:port]/

    To start a connection to a serial port, e.g. COM1:

    putty.exe -serial com1

    In order to start an existing saved session called sessionname',</span></strong>
    <strong><span style="color:#339966;"> use the
    -load’ option (described in section 3.8.3.1).

    putty.exe -load “session name”

    3.8.2 `-cleanup’

    If invoked with the `-cleanup’ option, rather than running as
    normal, PuTTY will remove its registry entries and random seed file
    from the local machine (after confirming with the user).

    Note that on multi-user systems, `-cleanup’ only removes registry
    entries and files associated with the currently logged-in user.

    3.8.3 Standard command-line options

    PuTTY and its associated tools support a range of command-line
    options, most of which are consistent across all the tools. This
    section lists the available options in all tools. Options which are
    specific to a particular tool are covered in the chapter about that
    tool.

    3.8.3.1 `-load’: load a saved session

    The `-load’ option causes PuTTY to load configuration details out
    of a saved session. If these details include a host name, then this
    option is all you need to make PuTTY start a session.

    You need double quotes around the session name if it contains
    spaces.

    If you want to create a Windows shortcut to start a PuTTY saved
    session, this is the option you should use: your shortcut should
    call something like

    d:\path\to\putty.exe -load “my session”

    (Note that PuTTY itself supports an alternative form of this option,
    for backwards compatibility. If you execute putty @sessionname' it
    will have the same effect as
    putty -load “sessionname”‘. With the
    @' form, no double quotes are required, and the@’ sign must be
    the very first thing on the command line. This form of the option is
    deprecated.)

    3.8.3.2 Selecting a protocol: -ssh',-telnet’, -rlogin',-raw’ `-
    serial’

    To choose which protocol you want to connect with, you can use one
    of these options:

    • `-ssh’ selects the SSH protocol.
  • `-telnet’ selects the Telnet protocol.

  • `-rlogin’ selects the Rlogin protocol.

  • `-raw’ selects the raw protocol.

  • `-serial’ selects a serial connection.

  • These options are not available in the file transfer tools PSCP and
    PSFTP (which only work with the SSH protocol).

    These options are equivalent to the protocol selection buttons
    in the Session panel of the PuTTY configuration box (see section
    4.1.1).

    3.8.3.3 `-v’: increase verbosity

    Most of the PuTTY tools can be made to tell you more about what they
    are doing by supplying the `-v’ option. If you are having trouble
    when making a connection, or you’re simply curious, you can turn
    this switch on and hope to find out more about what is happening.

    3.8.3.4 `-l’: specify a login name

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

    These options are equivalent to the username selection box in
    the Connection panel of the PuTTY configuration box (see section
    4.14.1).

    3.8.3.5 -L',-R’ and `-D’: set up port forwardings

    As well as setting up port forwardings in the PuTTY configuration
    (see section 4.25), you can also set up forwardings 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 something like one of
    these:

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

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

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

    To specify an IP address for the listening end of the tunnel,
    prepend it to the argument:

    plink -L 127.0.0.5:23:localhost:23 myhost

    To set up SOCKS-based dynamic port forwarding on a local port, use
    the `-D’ option. For this one you only have to pass the port number:

    putty -D 4096 -load mysession

    For general information on port forwarding, see section 3.5.

    These options are not available in the file transfer tools PSCP and
    PSFTP.

    3.8.3.6 `-m’: read a remote command or script from a file

    The -m' option performs a similar function to theRemote command’
    box in the SSH panel of the PuTTY configuration box (see section
    4.18.1). However, the `-m’ option expects to be given a local file
    name, and it will read a command from that file.

    With some servers (particularly Unix systems), you can even put
    multiple lines in this file and execute more than one command in
    sequence, or a whole shell script; but this is arguably an abuse,
    and cannot be expected to work on all servers. In particular, it is
    known not to work with certain `embedded’ servers, such as Cisco
    routers.

    This option is not available in the file transfer tools PSCP and
    PSFTP.

    3.8.3.7 `-P’: specify a port number

    The `-P’ option is used to specify the port number to connect to. If
    you have a Telnet server running on port 9696 of a machine instead
    of port 23, for example:

    putty -telnet -P 9696 host.name
    plink -telnet -P 9696 host.name

    (Note that this option is more useful in Plink than in PuTTY,
    because in PuTTY you can write `putty -telnet host.name 9696′ in any
    case.)

    This option is equivalent to the port number control in the Session
    panel of the PuTTY configuration box (see section 4.1.1).

    3.8.3.8 `-pw’: specify a password

    A simple way to automate a remote login is to supply your password
    on the 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.

    Note that the `-pw’ option only works when you are using the SSH
    protocol. Due to fundamental limitations of Telnet and Rlogin, these
    protocols do not support automated password authentication.

    3.8.3.9 -agent' and-noagent’: control use of Pageant for authentication

    3.8.3.10 -A' and-a’: control agent forwarding

    3.8.3.11 -X' and-x’: control X11 forwarding

    The -X' option turns on X11 forwarding in SSH, and-x’ turns it
    off. These options are only meaningful if you are using SSH.

    For information on X11 forwarding, see section 3.4.

    These options are equivalent to the X11 forwarding checkbox in the
    X11 panel of the PuTTY configuration box (see section 4.24).

    These options are not available in the file transfer tools PSCP and
    PSFTP.

    3.8.3.12 -t' and-T’: control pseudo-terminal allocation

    The -t' option ensures PuTTY attempts to allocate a pseudo-terminal
    at the server, and
    -T’ stops it from allocating one. These options
    are only meaningful if you are using SSH.

    These options are equivalent to the `Don’t allocate a pseudo-
    terminal’ checkbox in the SSH panel of the PuTTY configuration box
    (see section 4.23.1).

    These options are not available in the file transfer tools PSCP and
    PSFTP.

    3.8.3.13 `-N’: suppress starting a shell or command

    3.8.3.14 `-nc’: make a remote network connection in place of a remote shell
    or command

    3.8.3.15 `-C’: enable compression

    The `-C’ option enables compression of the data sent across the
    network. This option is only meaningful if you are using SSH.

    This option is equivalent to the `Enable compression’ checkbox in
    the SSH panel of the PuTTY configuration box (see section 4.18.3).

    3.8.3.16 -1' and-2′: specify an SSH protocol version

    3.8.3.17 -4' and-6′: specify an Internet protocol version

    3.8.3.18 `-i’: specify an SSH private key

    3.8.3.19 `-loghost’: specify a logical host name

    This option overrides PuTTY’s normal SSH host key caching policy by
    telling it the name of the host you expect your connection to end up
    at (in cases where this differs from the location PuTTY thinks it’s
    connecting to). It can be a plain host name, or a host name followed
    by a colon and a port number. See section 4.13.5 for more detail on
    this.

    3.8.3.20 `-hostkey’: manually specify an expected host key

    This option overrides PuTTY’s normal SSH host key caching policy
    by telling it exactly what host key to expect, which can be
    useful if the normal automatic host key store in the Registry is
    unavailable. The argument to this option should be either a host key
    fingerprint, or an SSH-2 public key blob. See section 4.19.3 for
    more information.

    You can specify this option more than once if you want to configure
    more than one key to be accepted.

    3.8.3.21 `-pgpfp’: display PGP key fingerprints

    3.8.3.22 `-sercfg’: specify serial port configuration

    This option specifies the configuration parameters for the serial
    port (baud rate, stop bits etc). Its argument is interpreted as
    a comma-separated list of configuration options, which can be as
    follows:

    • Any single digit from 5 to 9 sets the number of data bits.
  • 1',1.5′ or `2′ sets the number of stop bits.

  • Any other numeric string is interpreted as a baud rate.

  • A single lower-case letter specifies the parity: n' for none,o’ for odd, e' for even,m’ for mark and `s’ for space.

  • A single upper-case letter specifies the flow control: N' for
    none,
    X’ for XON/XOFF, R' for RTS/CTS andD’ for DSR/DTR.

  • For example, `-sercfg 19200,8,n,1,N’ denotes a baud rate of 19200, 8
    data bits, no parity, 1 stop bit and no flow control.

    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.

    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.

    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 Connection type' radio buttons let you choose what type
    of connection you want to make: a raw connection, a Telnet
    connection, an Rlogin connection, an SSH connection, or a
    connection to a local serial line. (See section 1.2 for a
    summary of the differences between SSH, Telnet and rlogin; see
    section 3.6 for an explanation of
    raw’ connections; see section
    3.7 for information about using a serial line.)

  • 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, you will almost certainly need to fill in the
    Port’ box yourself.

  • If you select Serial' from theConnection type’ radio buttons,
    the Host Name' andPort’ boxes are replaced by Serial line' andSpeed’; see section 4.27 for more details of these.

    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.

    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.

    You can also save settings in mid-session, from the `Change
    Settings’ dialog. Settings changed since the start of the
    session will be saved with their current values; as well as
    settings changed through the dialog, this includes changes in
    window size, window title changes sent by the server, and so on.

    • 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,
    and press the `Save’ button. The new settings will be saved over
    the top of the old ones.

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

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

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

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

    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:

    • `None’. This is the default option; in this mode PuTTY will not
      create a log file at all.
  • `Printable output’. 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.

  • `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.

  • `SSH packets’. 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 (as well as Event Log
    entries). 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 can appear in the log file; see section 4.2.4 for
    options that may help to remove sensitive material from the log
    file before you send it to anyone else.

  • `SSH packets and raw data’. In this mode, as well as the
    decrypted packets (as in the previous mode), the raw
    (encrypted, compressed, etc) packets are also logged. This
    could be useful to diagnose corruption in transit. (The same
    caveats as the previous mode apply, of course.)

  • Note that the non-SSH logging options (Printable output' andAll
    session output’) only work with PuTTY proper; in programs without
    terminal emulation (such as Plink), they will have no effect, even
    if enabled via saved settings.

    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

    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.

    4.2.3 `Flush log file frequently’

    This option allows you to control how frequently logged data is
    flushed to disc. By default, PuTTY will flush data as soon as it
    is displayed, so that if you view the log file while a session is
    still open, it will be up to date; and if the client system crashes,
    there’s a greater chance that the data will be preserved.

    However, this can incur a performance penalty. If PuTTY is running
    slowly with logging enabled, you could try unchecking this option.
    Be warned that the log file may not always be up to date as a result
    (although it will of course be flushed when it is closed, for
    instance at the end of a session).

    4.2.4 Options specific to SSH packet logging

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

    4.2.4.1 `Omit known password fields’

    When checked, decrypted 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.

    4.2.4.2 `Omit session data’

    When checked, all decrypted `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.

    4.3 The Terminal panel

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

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

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

    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

    4.3.4 `Implicit LF in every CR’

    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 CR, and so the newly written line is
    overwritten by the following line. This option causes a line feed so
    that all lines are displayed.

    4.3.5 `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 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.

    4.3.6 `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 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.

    4.3.7 `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.

    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.14.3
    for details.

    You can include control characters in the answerback string using
    ^C' notation. (Use^~’ to get a literal `^’.)

    4.3.8 `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.

    4.3.9 `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.8). 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.

    4.3.10 Remote-controlled printing

    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.

    4.4 The Keyboard panel

    The Keyboard configuration panel allows you to control the behaviour
    of the keyboard in PuTTY. The correct state for many of these
    settings depends on what the server to which PuTTY is connecting
    expects. With a Unix server, this is likely to depend on the
    termcap' orterminfo’ entry it uses, which in turn is likely to be
    controlled by the `Terminal-type string’ setting in the Connection
    panel; see section 4.14.3 for details. If none of the settings here
    seems to help, you may find question A.7.15 to be useful.

    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 over SSH, PuTTY by default tells the server
    the value of this option (see section 4.23.2), so you may find that
    the Backspace key does the right thing either way. Similarly, 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 again 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.)

    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, sendESC [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.

    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 toESC [[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 toESC 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 toESC OS’.

  • In VT100+ mode, the function keys generate ESC OP' through toESC 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 toESC [{‘.

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

    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 toESC [D’. In application mode, they
    send ESC OA' through toESC 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.

    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.

    You can also disable application keypad mode completely, using the
    `Features’ configuration panel; see section 4.6.1.

    4.4.6 Using NetHack keypad mode

    PuTTY has a special mode for playing NetHack. You can enable it
    by selecting NetHack' in theInitial 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).

    In addition, pressing Shift or Ctrl with the keypad keys generate
    the Shift- or Ctrl-keys you would expect (e.g. keypad-7 generates
    y', so Shift-keypad-7 generatesY’ and Ctrl-keypad-7 generates
    Ctrl-Y); these commands tell 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.

    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
    `e-grave’ 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.

    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.

    (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.)

    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.

    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.
  • Make default system alert 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.

  • `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.

  • `Beep using the PC speaker’ is self-explanatory.

  • 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’.

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

    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.

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

    4.6 The Features panel

    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.

    4.6.1 Disabling application keypad and cursor keys

    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.

    4.6.2 Disabling 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 newsreadertrn’ 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).

    4.6.3 Disabling remote terminal resizing

    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.

    4.6.4 Disabling switching to the alternate screen

    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.

    4.6.5 Disabling remote window title changing

    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.

    4.6.6 Response to remote window title querying

    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 set it to
    Window title’ unless you really know what you
    are doing.

    There are three settings for this option:

    `None’

    PuTTY makes no response whatsoever to the relevant escape
    sequence. This may upset server-side software that is expecting
    some sort of response.

    `Empty string’

    PuTTY makes a well-formed response, but leaves it blank. Thus,
    server-side software that expects a response is kept happy,
    but an attacker cannot influence the response string. This is
    probably the setting you want if you have no better ideas.

    `Window title’

    PuTTY responds with the actual window title. This is dangerous
    for the reasons described above.

    4.6.7 Disabling destructive backspace

    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.

    4.6.8 Disabling remote character set configuration

    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.

    4.6.9 Disabling Arabic text shaping

    PuTTY supports shaping of Arabic text, which means that if your
    server sends text written in the basic Unicode Arabic alphabet then
    it will convert it to the correct display forms before printing it
    on the screen.

    If you are using full-screen software which was not expecting
    this to happen (especially if you are not an Arabic speaker and
    you unexpectedly find yourself dealing with Arabic text files in
    applications which are not Arabic-aware), you might find that the
    display becomes corrupted. By ticking this box, you can disable
    Arabic text shaping so that PuTTY displays precisely the characters
    it is told to display.

    You may also find you need to disable bidirectional text display;
    see section 4.6.10.

    4.6.10 Disabling bidirectional text display

    PuTTY supports bidirectional text display, which means that if your
    server sends text written in a language which is usually displayed
    from right to left (such as Arabic or Hebrew) then PuTTY will
    automatically flip it round so that it is displayed in the right
    direction on the screen.

    If you are using full-screen software which was not expecting
    this to happen (especially if you are not an Arabic speaker and
    you unexpectedly find yourself dealing with Arabic text files in
    applications which are not Arabic-aware), you might find that the
    display becomes corrupted. By ticking this box, you can disable
    bidirectional text display, so that PuTTY displays text from left to
    right in all situations.

    You may also find you need to disable Arabic text shaping; see
    section 4.6.9.

    4.7 The Window panel

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

    4.7.1 Setting the size of the PuTTY window

    The Columns' andRows’ 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.

    4.7.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 using its window furniture.

    There are four options here:

    • `Change the number of rows and columns’: the font size will not
      change. (This is the default.)
  • `Change the size of the font’: the number of rows and columns in
    the terminal will stay the same, and the font size will change.

  • `Change font size when maximised’: when the window is resized,
    the number of rows and columns will change, except when the
    window is maximised (or restored), when the font size will
    change. (In this mode, holding down the Alt key while resizing
    will also cause the font size to change.)

  • `Forbid resizing completely’: the terminal will refuse to be
    resized at all.

  • 4.7.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
    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’.

    4.7.4 `Push erased text into scrollback’

    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.

    4.8 The Appearance panel

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

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

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

    By default, you will be offered a choice from all the fixed-width
    fonts installed on the system, since VT100-style terminal handling
    expects a fixed-width font. If you tick the box marked `Allow
    selection of variable-pitch fonts’, however, PuTTY will offer
    variable-width fonts as well: if you select one of these, the font
    will be coerced into fixed-size character cells, which will probably
    not look very good (but can work OK with some fonts).

    4.8.3 `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.

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

    4.9 The Behaviour panel

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

    4.9.1 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 (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.)

    4.9.2 `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.

    4.9.3 `Window closes on ALT-F4′

    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.

    4.9.4 `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.

    4.9.5 `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.

    4.9.6 `Ensure window is always on top’

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

    4.9.7 `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.7.

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

    4.10.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. Similarly,
    PuTTY needs to know how to translate your keystrokes into the
    encoding the server expects. Unfortunately, there is no satisfactory
    mechanism for PuTTY and the server to communicate this information,
    so it must usually be manually configured.

    There are a lot of character sets to choose from. The `Remote
    character set’ option lets you select one.

    By default PuTTY will use the UTF-8 encoding of Unicode, which can
    represent pretty much any character; data coming from the server
    is interpreted as UTF-8, and keystrokes are sent UTF-8 encoded.
    This is what most modern distributions of Linux will expect by
    default. However, if this is wrong for your server, you can select a
    different character set using this control.

    A few other 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′.

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

    4.10.2 `Treat CJK ambiguous characters as wide’

    There are some Unicode characters whose width is not well-defined.
    In most contexts, such characters should be treated as single-
    width for the purposes of wrapping and so on; however, in some CJK
    contexts, they are better treated as double-width for historical
    reasons, and some server-side applications may expect them to be
    displayed as such. Setting this option will cause PuTTY to take the
    double-width interpretation.

    If you use legacy CJK applications, and you find your lines are
    wrapping in the wrong places, or you are having other display
    problems, you might want to play with this setting.

    This option only has any effect in UTF-8 mode (see section 4.10.1).

    4.10.3 `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.

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

    • `Use Unicode line drawing code points’ 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.
  • 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.

  • `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.

  • 4.10.5 Controlling copy and paste 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 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.

    4.11 The Selection panel

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

    4.11.1 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. The effect of this is that if you
    paste into (say) a word processor, the text will appear in the word
    processor in the same font, colour, and style (e.g. bold, underline)
    PuTTY was using to display it.

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

    4.11.2 Changing the actions of the mouse buttons

    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 theAction 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.)

    4.11.3 `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 newsreadertrn’ 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.

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

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

    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.

    4.12 The Colours panel

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

    4.12.1 `Allow terminal to specify ANSI colours’

    This option is enabled by default. If it is disabled, PuTTY will
    ignore any control sequences sent by the server to request coloured
    text.

    If you have a particularly garish application, you might want to
    turn this option off and make PuTTY only use the default foreground
    and background colours.

    4.12.2 `Allow terminal to use xterm 256-colour mode’

    This option is enabled by default. If it is disabled, PuTTY will
    ignore any control sequences sent by the server which use the
    extended 256-colour mode supported by recent versions of xterm.

    If you have an application which is supposed to use 256-colour mode
    and it isn’t working, you may find you need to tell your server that
    your terminal supports 256 colours. On Unix, you do this by ensuring
    that the setting of TERM describes a 256-colour-capable terminal.
    You can check this using a command such as `infocmp’:

    $ infocmp | grep colors
    colors#256, cols#80, it#8, lines#24, pairs#256,

    If you do not see colors#256' in the output, you may need to change
    your terminal setting. On modern Linux machines, you could try
    xterm-256color’.

    4.12.3 `Indicate bolded text by changing…’

    When the server sends a control sequence indicating that some text
    should be displayed in bold, PuTTY can handle this in several ways.
    It can either change the font for a bold version, or use the same
    font in a brighter colour, or it can do both (brighten the colour
    and embolden the font). This control lets you choose which.

    By default bold is indicated by colour, so non-bold text is
    displayed in light grey and bold text is displayed in bright white
    (and similarly in other colours). If you change the setting to The
    font' box, bold and non-bold text will be displayed in the same
    colour, and instead the font will change to indicate the difference.
    If you select
    Both’, the font and the colour will both change.

    Some applications rely on bold black' being distinguishable from a
    black background; if you choose
    The font’, their text may become
    invisible.

    4.12.4 `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.

    4.12.5 `Use system colours’

    Enabling this option will cause PuTTY to ignore the configured
    colours for Default Background/Foreground' andCursor Colour/Text’
    (see section 4.12.6), 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.3).

    4.12.6 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. (You may also edit the RGB
    values directly in the edit boxes, if you wish; each value is an
    integer from 0 to 255.)

    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
    chosen to indicate that by colour (see section 4.12.3), 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.)

    4.13 The Connection panel

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

    4.13.1 Using keepalives to prevent disconnection

    If you find your sessions are closing unexpectedly (most often with
    `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. (Other types of periodic network activity
    can cause this behaviour; in particular, SSH-2 re-keys can have this
    effect. See section 4.19.2.)

    Therefore, you might find that keepalives 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.3.)

    Note that if you are using SSH-1 and the server has a bug that makes
    it unable to deal with SSH-1 ignore messages (see section 4.26.1),
    enabling keepalives will have no effect.

    4.13.2 `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 for interactive
    connections.

    4.13.3 `Enable TCP keepalives’

    NOTE: TCP keepalives should not be confused with the application-
    level keepalives described in section 4.13.1. 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 are available on all connection types,
      including Raw and Rlogin.
  • The interval between TCP keepalives is usually much longer,
    typically two hours; this is set by the operating system, and
    cannot be configured within PuTTY.

  • If the operating system does not receive a response to a
    keepalive, it may send out more in quick succession and
    terminate the connection if no response is received.

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

    4.13.4 `Internet protocol’

    This option allows the user to select between the old and new
    Internet protocols and addressing schemes (IPv4 and IPv6). The
    selected protocol will be used for most outgoing network connections
    (including connections to proxies); however, tunnels have their own
    configuration, for which see section 4.25.2.

    The default setting is `Auto’, which means PuTTY will do something
    sensible and try to guess which protocol you wanted. (If you specify
    a literal Internet address, it will use whichever protocol that
    address implies. If you provide a hostname, it will see what kinds
    of address exist for that hostname; it will use IPv6 if there is an
    IPv6 address available, and fall back to IPv4 if not.)

    If you need to force PuTTY to use a particular protocol, you can
    explicitly set this to IPv4' orIPv6′.

    4.13.5 `Logical name of remote host’

    This allows you to tell PuTTY that the host it will really end up
    connecting to is different from where it thinks it is making a
    network connection.

    You might use this, for instance, if you had set up an SSH port
    forwarding in one PuTTY session so that connections to some
    arbitrary port (say, localhost port 10022) were forwarded to a
    second machine’s SSH port (say, foovax port 22), and then started a
    second PuTTY connecting to the forwarded port.

    In normal usage, the second PuTTY will access the host key cache
    under the host name and port it actually connected to (i.e.
    localhost port 10022 in this example). Using the logical host name
    option, however, you can configure the second PuTTY to cache the
    host key under the name of the host you know that it’s really
    going to end up talking to (here `foovax’).

    This can be useful if you expect to connect to the same actual
    server through many different channels (perhaps because your port
    forwarding arrangements keep changing): by consistently setting the
    logical host name, you can arrange that PuTTY will not keep asking
    you to reconfirm its host key. Conversely, if you expect to use the
    same local port number for port forwardings to lots of different
    servers, you probably didn’t want any particular server’s host key
    cached under that local port number. (For this latter case, you
    could also explicitly configure host keys in the relevant sessions;
    see section 4.19.3.)

    If you just enter a host name for this option, PuTTY will cache the
    SSH host key under the default SSH port for that host, irrespective
    of the port you really connected to (since the typical scenario is
    like the above example: you connect to a silly real port number and
    your connection ends up forwarded to the normal port-22 SSH server
    of some other machine). To override this, you can append a port
    number to the logical host name, separated by a colon. E.g. entering
    foovax:2200' as the logical host name will cause the host key to be
    cached as if you had connected to port 2200 of
    foovax’.

    If you provide a host name using this option, it is also displayed
    in other locations which contain the remote host name, such as the
    default window title and the default SSH password prompt. This
    reflects the fact that this is the host you’re really connecting
    to, which is more important than the mere means you happen to be
    using to contact that host. (This applies even if you’re using a
    protocol other than SSH.)

    4.14 The Data panel

    The Data panel allows you to configure various pieces of data which
    can be sent to the server to affect your connection at the far end.

    Each option on this panel applies to more than one protocol.
    Options which apply to only one protocol appear on that protocol’s
    configuration panels.

    4.14.1 `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.

    4.14.2 Use of system username

    When the previous box (section 4.14.1) is left blank, by default,
    PuTTY will prompt for a username at the time you make a connection.

    In some environments, such as the networks of large organisations
    implementing single sign-on, a more sensible default may be to
    use the name of the user logged in to the local operating system
    (if any); this is particularly likely to be useful with GSSAPI
    authentication (see section 4.22). This control allows you to change
    the default behaviour.

    The current system username is displayed in the dialog as a
    convenience. It is not saved in the configuration; if a saved
    session is later used by a different user, that user’s name will be
    used.

    4.14.3 `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. On a Unix server,
    this selects an entry from the termcap' orterminfo’ database that
    tells applications what control sequences to send to the terminal,
    and what character sequences to expect the keyboard to generate.

    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.

    4.14.4 `Terminal speeds’

    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.

    4.14.5 Setting environment variables on the server

    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 SSH-2
    servers are more likely to support it than older ones.

    This configuration data is not used in the SSH-1, 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’.

    4.15 The Proxy panel

    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, and also any extra connections made as a result of SSH port
    forwarding (see section 3.5).

    Note that unlike some software (such as web browsers), PuTTY does
    not attempt to automatically determine whether to use a proxy and
    (if so) which one to use for a given destination. If you need to use
    a proxy, it must always be explicitly configured.

    4.15.1 Setting the proxy type

    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.

    • Selecting `HTTP’ allows you to proxy your connections through a
      web server supporting the HTTP CONNECT command, as documented in
      RFC 2817.
  • Selecting SOCKS 4' orSOCKS 5′ allows you to proxy your
    connections through a SOCKS server.

  • Many firewalls implement a less formal type of proxy in which
    a user can make a Telnet connection directly to the firewall
    machine and enter a command such as connect myhost.com 22' to
    connect through to an external host. Selecting
    Telnet’ allows
    you to tell PuTTY to use this type of proxy.

  • Selecting `Local’ allows you to specify an arbitrary command
    on the local machine to act as a proxy. When the session is
    started, instead of creating a TCP connection, PuTTY runs the
    command (specified in section 4.15.5), and uses its standard
    input and output streams.

  • This could be used, for instance, to talk to some kind of
    network proxy that PuTTY does not natively support; or you could
    tunnel a connection over something other than TCP/IP entirely.

    If you want your local proxy command to make a secondary
    SSH connection to a proxy host and then tunnel the primary
    connection over that, you might well want the `-nc’ command-line
    option in Plink. See section 3.8.3.14 for more information.

    4.15.2 Excluding parts of the network from proxying

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

    4.15.3 Name resolution when using a proxy

    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,
    HTTP, and SOCKS5 proxies will have host names passed straight to
    them; SOCKS4 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.15.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.

    4.15.4 Username and password

    If your proxy requires authentication, you can enter a username and
    a password in the Username' andPassword’ 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:

    • Username and password authentication is supported for HTTP
      proxies and SOCKS 5 proxies.
  • With SOCKS 5, authentication is via CHAP if the proxy
    supports it (this is not supported in PuTTYtel); otherwise
    the password is sent to the proxy in plain text.

  • With HTTP proxying, the only currently supported
    authentication method is `basic’, where the password is sent
    to the proxy in plain text.

  • SOCKS 4 can use the `Username’ field, but does not support
    passwords.

  • You can specify a way to include a username and password in the
    Telnet/Local proxy command (see section 4.15.5).

  • 4.15.5 Specifying the Telnet or Local proxy command

    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.

    If you are using the Local proxy type, the local command to run is
    specified 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. The strings %proxyhost' and%proxyport’ will
    be replaced by the host details specified on the Proxy panel, if
    any (this is most likely to be useful for the Local proxy type). To
    get a literal %' sign, enter%%’.

    If a 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' andPassword’
    configuration fields will be ignored.

    4.16 The Telnet panel

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

    4.16.1 `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.

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

    4.16.3 `Keyboard sends Telnet special commands’

    If this box is checked, several key sequences will have their normal
    actions modified:

    • the Backspace key on the keyboard will send the Telnet special
      backspace code;
  • Control-C will send the Telnet special Interrupt Process code;

  • Control-Z will send the Telnet special Suspend Process code.

  • You probably shouldn’t enable this unless you know what you’re
    doing.

    4.16.4 `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.

    4.17 The Rlogin panel

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

    4.17.1 `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).

    4.18 The SSH panel

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

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

    Note that most servers will close the session after executing the
    command.

    4.18.2 `Don’t start a shell or command at all’

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

    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.

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

    4.18.4 `Preferred SSH protocol version’

    This allows you to select whether you would prefer to use SSH
    protocol version 1 or version 2, and whether to permit falling back
    to the other version.

    With the settings 1' and2′, 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' or2 only’ here, PuTTY will only connect if
    the server you connect to offers the SSH protocol version you have
    specified.

    You should normally leave this at the default, 2 only'. The older
    SSH-1 protocol is no longer developed, has many known cryptographic
    weaknesses, and is generally not considered to be secure. If you
    permit use of SSH-1 by selecting
    2′ instead of `2 only’, an active
    attacker can force downgrade to SSH-1 even if the server you’re
    connecting to supports SSH-2.

    PuTTY’s protocol 1 implementation is provided mainly for
    compatibility, and is no longer being enhanced.

    4.18.5 Sharing an SSH connection between PuTTY tools

    The controls in this box allow you to configure PuTTY to reuse an
    existing SSH connection, where possible.

    The SSH-2 protocol permits you to run multiple data channels over
    the same SSH connection, so that you can log in just once (and do
    the expensive encryption setup just once) and then have more than
    one terminal window open.

    Each instance of PuTTY can still run at most one terminal session,
    but using the controls in this box, you can configure PuTTY to check
    if another instance of itself has already connected to the target
    host, and if so, share that instance’s SSH connection instead of
    starting a separate new one.

    To enable this feature, just tick the box Share SSH connections if
    possible'. Then, whenever you start up a PuTTY session connecting to
    a particular host, it will try to reuse an existing SSH connection
    if one is available. For example, selecting
    Duplicate Session’ from
    the system menu will launch another session on the same host, and if
    sharing is enabled then it will reuse the existing SSH connection.

    When this mode is in use, the first PuTTY that connected to a given
    server becomes the upstream', which means that it is the one
    managing the real SSH connection. All subsequent PuTTYs which reuse
    the connection are referred to as
    downstreams’: they do not connect
    to the real server at all, but instead connect to the upstream PuTTY
    via local inter-process communication methods.

    For this system to be activated, both the upstream and downstream
    instances of PuTTY must have the sharing option enabled.

    The upstream PuTTY can therefore not terminate until all its
    downstreams have closed. This is similar to the effect you get with
    port forwarding or X11 forwarding, in which a PuTTY whose terminal
    session has already finished will still remain open so as to keep
    serving forwarded connections.

    In case you need to configure this system in more detail, there
    are two additional checkboxes which allow you to specify whether a
    particular PuTTY can act as an upstream or a downstream or both.
    (These boxes only take effect if the main `Share SSH connections if
    possible’ box is also ticked.) By default both of these boxes are
    ticked, so that multiple PuTTYs started from the same configuration
    will designate one of themselves as the upstream and share a single
    connection; but if for some reason you need a particular PuTTY
    configuration not to be an upstream (e.g. because you definitely
    need it to close promptly) or not to be a downstream (e.g. because
    it needs to do its own authentication using a special private key)
    then you can untick one or the other of these boxes.

    I have referred to `PuTTY’ throughout the above discussion, but
    all the other PuTTY tools which make SSH connections can use this
    mechanism too. For example, if PSCP or PSFTP loads a configuration
    with sharing enabled, then it can act as a downstream and use an
    existing SSH connection set up by an instance of GUI PuTTY. The one
    special case is that PSCP and PSFTP will never act as upstreams.

    4.19 The Kex panel

    The Kex panel (short for `key exchange’) allows you to configure
    options related to SSH-2 key exchange.

    Key exchange occurs at the start of an SSH connection (and
    occasionally thereafter); it establishes a shared secret that
    is used as the basis for all of SSH’s security features. It is
    therefore very important for the security of the connection that the
    key exchange is secure.

    Key exchange is a cryptographically intensive process; if either
    the client or the server is a relatively slow machine, the slower
    methods may take several tens of seconds to complete.

    If connection startup is too slow, or the connection hangs
    periodically, you may want to try changing these settings.

    If you don’t understand what any of this means, it’s safe to leave
    these settings alone.

    This entire panel is only relevant to SSH protocol version 2; none
    of these settings affect SSH-1 at all.

    4.19.1 Key exchange algorithm selection

    PuTTY supports a variety of SSH-2 key exchange methods, and allows
    you to choose which one you prefer to use; configuration is similar
    to cipher selection (see section 4.20).

    PuTTY currently supports the following varieties of Diffie-Hellman
    key exchange:

    • `Group 14′: a well-known 2048-bit group.
  • `Group 1′: a well-known 1024-bit group. This is less secure than
    group 14, but may be faster with slow client or server machines,
    and may be the only method supported by older server software.

  • `Group exchange’: with this method, instead of using a fixed
    group, PuTTY requests that the server suggest a group to use for
    key exchange; the server can avoid groups known to be weak, and
    possibly invent new ones over time, without any changes required
    to PuTTY’s configuration. We recommend use of this method, if
    possible.

  • In addition, PuTTY supports RSA key exchange, which requires much
    less computational effort on the part of the client, and somewhat
    less on the part of the server, than Diffie-Hellman key exchange.

    If the first algorithm PuTTY finds is below the `warn below here’
    line, you will see a warning box when you make the connection,
    similar to that for cipher selection (see section 4.20).

    4.19.2 Repeat key exchange

    If the session key negotiated at connection startup is used too much
    or for too long, it may become feasible to mount attacks against the
    SSH connection. Therefore, the SSH-2 protocol specifies that a new
    key exchange should take place every so often; this can be initiated
    by either the client or the server.

    While this renegotiation is taking place, no data can pass through
    the SSH connection, so it may appear to `freeze’. (The occurrence
    of repeat key exchange is noted in the Event Log; see section
    3.1.3.1.) Usually the same algorithm is used as at the start of the
    connection, with a similar overhead.

    These options control how often PuTTY will initiate a repeat key
    exchange (`rekey’). You can also force a key exchange at any time
    from the Special Commands menu (see section 3.1.3.2).

    • `Max minutes before rekey’ specifies the amount of time that
      is allowed to elapse before a rekey is initiated. If this is
      set to zero, PuTTY will not rekey due to elapsed time. The SSH-
      2 protocol specification recommends a timeout of at most 60
      minutes.

    You might have a need to disable time-based rekeys completely
    for the same reasons that keepalives aren’t always helpful. If
    you anticipate suffering a network dropout of several hours in
    the middle of an SSH connection, but were not actually planning
    to send data down that connection during those hours, then an
    attempted rekey in the middle of the dropout will probably cause
    the connection to be abandoned, whereas if rekeys are disabled
    then the connection should in principle survive (in the absence
    of interfering firewalls). See section 4.13.1 for more discussion
    of these issues; for these purposes, rekeys have much the same
    properties as keepalives. (Except that rekeys have cryptographic
    value in themselves, so you should bear that in mind when deciding
    whether to turn them off.) Note, however, the the SSH server can
    still initiate rekeys.

    • `Max data before rekey’ specifies the amount of data (in bytes)
      that is permitted to flow in either direction before a rekey is
      initiated. If this is set to zero, PuTTY will not rekey due to
      transferred data. The SSH-2 protocol specification recommends a
      limit of at most 1 gigabyte.

    As well as specifying a value in bytes, the following shorthand
    can be used:

    • `1k’ specifies 1 kilobyte (1024 bytes).
  • `1M’ specifies 1 megabyte (1024 kilobytes).

  • `1G’ specifies 1 gigabyte (1024 megabytes).

  • Disabling data-based rekeys entirely is a bad idea. The integrity,
    and to a lesser extent, confidentiality of the SSH-2 protocol depend
    in part on rekeys occuring before a 32-bit packet sequence number
    wraps around. Unlike time-based rekeys, data-based rekeys won’t
    occur when the SSH connection is idle, so they shouldn’t cause the
    same problems. The SSH-1 protocol, incidentally, has even weaker
    integrity protection than SSH-2 without rekeys.

    4.19.3 Manually configuring host keys

    In some situations, if PuTTY’s automated host key management is not
    doing what you need, you might need to manually configure PuTTY to
    accept a specific host key, or one of a specific set of host keys.

    One reason why you might want to do this is because the host name
    PuTTY is connecting to is using round-robin DNS to return one of
    multiple actual servers, and they all have different host keys. In
    that situation, you might need to configure PuTTY to accept any of
    a list of host keys for the possible servers, while still rejecting
    any key not in that list.

    Another reason is if PuTTY’s automated host key management is
    completely unavailable, e.g. because PuTTY (or Plink or PSFTP, etc)
    is running in a Windows environment without access to the Registry.
    In that situation, you will probably want to use the -hostkey
    command-line option to configure the expected host key(s); see
    section 3.8.3.20.

    For situations where PuTTY’s automated host key management simply
    picks the wrong host name to store a key under, you may want to
    consider setting a `logical host name’ instead; see section 4.13.5.

    To configure manual host keys via the GUI, enter some text
    describing the host key into the edit box in the Manually configure
    host keys for this connection' container, and press the
    Add’
    button. The text will appear in the Host keys or fingerprints
    to accept' list box. You can remove keys again with the
    Remove’
    button.

    The text describing a host key can be in one of the following
    formats:

    • An MD5-based host key fingerprint of the form displayed in
      PuTTY’s Event Log and host key dialog boxes, i.e. sixteen 2-
      digit hex numbers separated by colons.
  • A base64-encoded blob describing an SSH-2 public key in
    OpenSSH’s one-line public key format. How you acquire
    a public key in this format is server-dependent; on an
    OpenSSH server it can typically be found in a location like
    `/etc/ssh/ssh_host_rsa_key.pub’.

  • If this box contains at least one host key or fingerprint when PuTTY
    makes an SSH connection, then PuTTY’s automated host key management
    is completely bypassed: the connection will be permitted if and only
    if the host key presented by the server is one of the keys listed
    in this box, and the host key store in the Registry will be neither
    read nor written.

    If the box is empty (as it usually is), then PuTTY’s automated host
    key management will work as normal.

    4.20 The Cipher panel

    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:

    • AES (Rijndael) – 256, 192, or 128-bit SDCTR or CBC (SSH-2 only)
  • Arcfour (RC4) – 256 or 128-bit stream cipher (SSH-2 only)

  • Blowfish – 256-bit SDCTR (SSH-2 only) or 128-bit CBC

  • Triple-DES – 168-bit SDCTR (SSH-2 only) or CBC

  • Single-DES – 56-bit CBC (see below for SSH-2)

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

    4.21 The Auth panel

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

    4.21.1 `Bypass authentication entirely’

    In SSH-2, it is possible to establish a connection without using
    SSH’s mechanisms to identify or authenticate oneself to the server.
    Some servers may prefer to handle authentication in the data
    channel, for instance, or may simply require no authentication
    whatsoever.

    By default, PuTTY assumes the server requires authentication (most
    do), and thus must provide a username. If you find you are getting
    unwanted username prompts, you could try checking this option.

    This option only affects SSH-2 connections. SSH-1 connections always
    require an authentication step.

    4.21.2 `Display pre-authentication banner’

    SSH-2 servers can provide a message for clients to display to the
    prospective user before the user logs in; this is sometimes known
    as a pre-authentication `banner’. Typically this is used to provide
    information about the server and legal notices.

    By default, PuTTY displays this message before prompting for a
    password or similar credentials (although, unfortunately, not before
    prompting for a login name, due to the nature of the protocol
    design). By unchecking this option, display of the banner can be
    suppressed entirely.

    4.21.3 `Attempt authentication using Pageant’

    If this option is enabled, then PuTTY will look for Pageant (the
    SSH private-key storage agent) and attempt to authenticate with any
    suitable public keys Pageant currently holds.

    This behaviour is almost always desirable, and is therefore enabled
    by default. In rare cases you might need to turn it off in order
    to force authentication by some non-public-key method such as
    passwords.

    This option can also be controlled using the `-noagent’ command-line
    option. See section 3.8.3.9.

    See chapter 9 for more information about Pageant in general.

    4.21.4 `Attempt TIS or CryptoCard authentication’

    TIS and CryptoCard authentication are (despite their names) generic
    forms of simple challenge/response 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. They
    can even be used to prompt for simple passwords.

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

    4.21.5 `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.

    4.21.6 `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.

    4.21.7 `Allow attempted changes of username in SSH-2′

    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.

    4.21.8 `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.

    This key must be in PuTTY’s native format (`*.PPK’). If you have a
    private key in another format that you want to use with PuTTY, see
    section 8.2.12.

    You can use the authentication agent Pageant so that you do not
    need to explicitly configure a key here; see chapter 9. If a file
    is specified here with Pageant running, PuTTY will first try asking
    Pageant to authenticate with that key, and ignore any other keys
    Pageant may have. If that fails, PuTTY will ask for a passphrase as
    normal.

    4.22 The GSSAPI panel

    The GSSAPI' subpanel of theAuth’ panel controls the use of
    GSSAPI authentication. This is a mechanism which delegates the
    authentication exchange to a library elsewhere on the client
    machine, which in principle can authenticate in many different ways
    but in practice is usually used with the Kerberos single sign-on
    protocol.

    GSSAPI is only available in the SSH-2 protocol.

    The topmost control on the GSSAPI subpanel is the checkbox labelled
    `Attempt GSSAPI authentication’. If this is disabled, GSSAPI will
    not be attempted at all and the rest of this panel is unused. If it
    is enabled, GSSAPI authentication will be attempted, and (typically)
    if your client machine has valid Kerberos credentials loaded, then
    PuTTY should be able to authenticate automatically to servers that
    support Kerberos logins.

    4.22.1 `Allow GSSAPI credential delegation’

    GSSAPI credential delegation is a mechanism for passing on your
    Kerberos (or other) identity to the session on the SSH server. If
    you enable this option, then not only will PuTTY be able to log in
    automatically to a server that accepts your Kerberos credentials,
    but also you will be able to connect out from that server to other
    Kerberos-supporting services and use the same credentials just as
    automatically.

    (This option is the Kerberos analogue of SSH agent forwarding; see
    section 9.4 for some information on that.)

    Note that, like SSH agent forwarding, there is a security
    implication in the use of this option: the administrator of
    the server you connect to, or anyone else who has cracked the
    administrator account on that server, could fake your identity
    when connecting to further Kerberos-supporting services. However,
    Kerberos sites are typically run by a central authority, so the
    administrator of one server is likely to already have access to the
    other services too; so this would typically be less of a risk than
    SSH agent forwarding.

    4.22.2 Preference order for GSSAPI libraries

    GSSAPI is a mechanism which allows more than one authentication
    method to be accessed through the same interface. Therefore, more
    than one authentication library may exist on your system which can
    be accessed using GSSAPI.

    PuTTY contains native support for a few well-known such libraries,
    and will look for all of them on your system and use whichever it
    finds. If more than one exists on your system and you need to use a
    specific one, you can adjust the order in which it will search using
    this preference list control.

    One of the options in the preference list is to use a user-specified
    GSSAPI library. If the library you want to use is not mentioned by
    name in PuTTY’s list of options, you can enter its full pathname in
    the User-supplied GSSAPI library path' field, and move theUser-
    supplied GSSAPI library’ option in the preference list to make sure
    it is selected before anything else.

    4.23 The TTY panel

    The TTY panel lets you configure the remote pseudo-terminal.

    4.23.1 `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.

    4.23.2 Sending terminal modes

    The SSH protocol allows the client to send `terminal modes’ for
    the remote pseudo-terminal. These usually control the server’s
    expectation of the local terminal’s behaviour.

    If your server does not have sensible defaults for these modes, you
    may find that changing them here helps. If you don’t understand any
    of this, it’s safe to leave these settings alone.

    (None of these settings will have any effect if no pseudo-terminal
    is requested or allocated.)

    You can add or modify a mode by selecting it from the drop-down
    list, choosing whether it’s set automatically or to a specific value
    with the radio buttons and edit box, and hitting Add'. A mode (or
    several) can be removed from the list by selecting them and hitting
    Remove’. The effect of the mode list is as follows:

    • If a mode is not on the list, it will not be specified to the
      server under any circumstances.
  • If a mode is on the list:

  • If the `Auto’ option is selected, the PuTTY tools will
    decide whether to specify that mode to the server, and if
    so, will send a sensible value.

  • PuTTY proper will send modes that it has an opinion on
    (currently only the code for the Backspace key, ERASE).
    Plink on Unix will propagate appropriate modes from the
    local terminal, if any.

    • If a value is specified, it will be sent to the server under
      all circumstances. The precise syntax of the value box
      depends on the mode.

    By default, all of the available modes are listed as `Auto’, which
    should do the right thing in most circumstances.

    The precise effect of each setting, if any, is up to the server.
    Their names come from POSIX and other Unix systems, and they are
    most likely to have a useful effect on such systems. (These are the
    same settings that can usually be changed using the `stty’ command
    once logged in to such servers.)

    Some notable modes are described below; for fuller explanations, see
    your server documentation.

    • ERASE is the character that when typed by the user will delete
      one space to the left. When set to `Auto’ (the default setting),
      this follows the setting of the local Backspace key in PuTTY
      (see section 4.4.1).

    This and other special characters are specified using ^C'
    notation for Ctrl-C, and so on. Use
    ^<27>’ or ^&lt;0x1B&gt;' to
    specify a character numerically, and
    ^~’ to get a literal `^’.
    Other non-control characters are denoted by themselves. Leaving
    the box entirely blank indicates that no character should be
    assigned to the specified function, although this may not be
    supported by all servers.

    • QUIT is a special character that usually forcefully ends the
      current process on the server (SIGQUIT). On many servers its
      default setting is Ctrl-backslash (`^\’), which is easy to
      accidentally invoke on many keyboards. If this is getting in
      your way, you may want to change it to another character or turn
      it off entirely.
  • Boolean modes such as ECHO and ICANON can be specified in PuTTY
    in a variety of ways, such as true/false, yes/no, and 0/1.

  • Terminal speeds are configured elsewhere; see section 4.14.4.

  • 4.24 The X11 panel

    The X11 panel allows you to configure forwarding of X11 over an SSH
    connection.

    If your server lets you run X Window System graphical 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 will 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.

    4.24.1 Remote X11 authentication

    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:

    • Some X clients probably do not even support XDM-AUTHORIZATION-
      1, so they will not know what to do with the data PuTTY has
      provided.
  • This authentication mechanism will only work in SSH-2. In SSH-
    1, the SSH server does not tell the client the source address
    of a forwarded connection in a machine-readable format, so it’s
    impossible to verify the XDM-AUTHORIZATION-1 data.

  • You may find this feature causes problems with some SSH servers,
    which will not clean up 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.

    4.24.2 X authority file for local display

    If you are using X11 forwarding, the local X server to which your
    forwarded connections are eventually directed may itself require
    authorisation.

    Some Windows X servers do not require this: they do authorisation
    by simpler means, such as accepting any connection from the local
    machine but not from anywhere else. However, if your X server does
    require authorisation, then PuTTY needs to know what authorisation
    is required.

    One way in which this data might be made available is for the X
    server to store it somewhere in a file which has the same format
    as the Unix `.Xauthority’ file. If this is how your Windows X
    server works, then you can tell PuTTY where to find this file by
    configuring this option. By default, PuTTY will not attempt to find
    any authorisation for your local display.

    4.25 The Tunnels panel

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

    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' orRemote’ 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’). Alternatively, select `Dynamic’ if you want PuTTY to
      provide a local SOCKS 4/4A/5 proxy on a local port (note that
      this proxy only supports TCP connections; the SSH protocol does
      not support forwarding UDP).
  • 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.

  • If you have selected Local' orRemote’ (this step is not
    needed with Dynamic'), 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'. (If you need to enter
    a literal IPv6 address, enclose it in square brackets, for
    instance
    [::1]:2200′.)

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

    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.

    In place of port numbers, you can enter service names, if they are
    known to the local system. For instance, in the Destination' box,
    you could enter
    popserver.example.com:pop3′.

    You can modify the currently active set of port forwardings in mid-
    session using `Change Settings’ (see section 3.1.3.4). If you delete
    a local or dynamic port forwarding in mid-session, PuTTY will stop
    listening for connections on that port, so it can be re-used by
    another program. If you delete a remote port forwarding, note that:

    • The SSH-1 protocol contains no mechanism for asking the server
      to stop listening on a remote port.
  • The SSH-2 protocol does contain such a mechanism, but not all
    SSH servers support it. (In particular, OpenSSH does not support
    it in any version earlier than 3.9.)

  • If you ask to delete a remote port forwarding and PuTTY cannot make
    the server actually stop listening on the port, it will instead
    just start refusing incoming connections on that port. Therefore,
    although the port cannot be reused by another program, you can at
    least be reasonably sure that server-side programs can no longer
    access the service at your end of the port forwarding.

    If you delete a forwarding, any existing connections established
    using that forwarding remain open. Similarly, changes to global
    settings such as `Local ports accept connections from other hosts’
    only take effect on new forwardings.

    If the connection you are forwarding over SSH is itself a second
    SSH connection made by another copy of PuTTY, you might find the
    `logical host name’ configuration option useful to warn PuTTY of
    which host key it should be expecting. See section 4.13.5 for
    details of this.

    4.25.1 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. (This also applies to dynamic SOCKS forwarding.)
  • 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).

  • 4.25.2 Selecting Internet protocol version for forwarded ports

    This switch allows you to select a specific Internet protocol (IPv4
    or IPv6) for the local end of a forwarded port. By default, it is
    set on `Auto’, which means that:

    • for a local-to-remote port forwarding, PuTTY will listen for
      incoming connections in both IPv4 and (if available) IPv6
  • for a remote-to-local port forwarding, PuTTY will choose a
    sensible protocol for the outgoing connection.

  • This overrides the general Internet protocol version preference on
    the Connection panel (see section 4.13.4).

    Note that some operating systems may listen for incoming connections
    in IPv4 even if you specifically asked for IPv6, because their IPv4
    and IPv6 protocol stacks are linked together. Apparently Linux does
    this, and Windows does not. So if you’re running PuTTY on Windows
    and you tick IPv6' for a local or dynamic port forwarding, it will
    _only_ be usable by connecting to it using IPv6; whereas if you do
    the same on Linux, you can also use it with IPv4. However, ticking
    Auto’ should always give you a port which you can connect to using
    either protocol.

    4.26 The Bugs and More Bugs panels

    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 and More Bugs panels (there are two because we have so many
    bug compatibility modes) allow you to manually configure the bugs
    PuTTY expects to see in the server. Each bug can be configured in
    three states:

    • `Off’: PuTTY will assume the server does not have the bug.
  • `On’: PuTTY will assume the server does have the bug.

  • `Auto’: PuTTY will use the server’s version number announcement
    to try to guess whether or not the server has the bug.

  • 4.26.1 `Chokes on SSH-1 ignore messages’

    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 SSH-1, 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.1).

    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 SSH-1 password-
    length eavesdropping. See section 4.26.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.

    4.26.2 `Refuses all SSH-1 password camouflage’

    When talking to an SSH-1 server which cannot deal with ignore
    messages (see section 4.26.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 SSH-
    1 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 assume that neither ignore
    messages nor padding are acceptable, and that it thus has 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 SSH-1-specific bug. SSH-2 is secure against this type of
    attack.

    4.26.3 `Chokes on SSH-1 RSA authentication’

    Some SSH-1 servers cannot deal with RSA authentication messages at
    all. If Pageant is running and contains any SSH-1 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 SSH-1-specific bug.

    4.26.4 `Chokes on SSH-2 ignore messages’

    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 in
    SSH-2 to confuse the encrypted data stream and make it harder to
    cryptanalyse. It also uses ignore messages for connection keepalives
    (see section 4.13.1).

    If it believes the server to have this bug, PuTTY will stop using
    ignore messages. 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 less cryptographically secure than it could be.

    4.26.5 Chokes on PuTTY's SSH-2winadj’ requests’

    PuTTY sometimes sends a special request to SSH servers in the middle
    of channel data, with the name winadj@putty.projects.tartarus.org
    (see section F.1). The purpose of this request is to measure the
    round-trip time to the server, which PuTTY uses to tune its flow
    control. The server does not actually have to understand the
    message; it is expected to send back a SSH_MSG_CHANNEL_FAILURE
    message indicating that it didn’t understand it. (All PuTTY needs
    for its timing calculations is some kind of response.)

    It has been known for some SSH servers to get confused by this
    message in one way or another – because it has a long name, or
    because they can’t cope with unrecognised request names even to the
    extent of sending back the correct failure response, or because they
    handle it sensibly but fill up the server’s log file with pointless
    spam, or whatever. PuTTY therefore supports this bug-compatibility
    flag: if it believes the server has this bug, it will never send
    its `winadj@putty.projects.tartarus.org’ request, and will make do
    without its timing data.

    4.26.6 `Miscomputes SSH-2 HMAC keys’

    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 SSH-2-specific bug.

    4.26.7 `Miscomputes SSH-2 encryption keys’

    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 SSH-2-specific bug.

    4.26.8 `Requires padding on SSH-2 RSA signatures’

    Versions below 3.3 of OpenSSH require SSH-2 RSA signatures to be
    padded with zero bytes to the same length as the RSA key modulus.
    The SSH-2 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 SSH-2-specific bug.

    4.26.9 `Misuses the session ID in SSH-2 PK auth’

    Versions below 2.3 of OpenSSH require SSH-2 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,
    SSH-2 public-key authentication will fail.

    This is an SSH-2-specific bug.

    4.26.10 `Handles SSH-2 key re-exchange badly’

    Some SSH servers cannot cope with repeat key exchange at all, and
    will ignore attempts by the client to start one. Since PuTTY pauses
    the session while performing a repeat key exchange, the effect of
    this would be to cause the session to hang after an hour (unless
    you have your rekey timeout set differently; see section 4.19.2 for
    more about rekeys). Other, very old, SSH servers handle repeat key
    exchange even more badly, and disconnect upon receiving a repeat key
    exchange request.

    If this bug is detected, PuTTY will never initiate a repeat key
    exchange. If this bug is enabled when talking to a correct server,
    the session should still function, but may be less secure than you
    would expect.

    This is an SSH-2-specific bug.

    4.26.11 `Ignores SSH-2 maximum packet size’

    When an SSH-2 channel is set up, each end announces the maximum size
    of data packet that it is willing to receive for that channel. Some
    servers ignore PuTTY’s announcement and send packets larger than
    PuTTY is willing to accept, causing it to report `Incoming packet
    was garbled on decryption’.

    If this bug is detected, PuTTY never allows the channel’s flow-
    control window to grow large enough to allow the server to send an
    over-sized packet. If this bug is enabled when talking to a correct
    server, the session will work correctly, but download performance
    will be less than it could be.

    4.26.12 `Replies to requests on closed channels’

    The SSH protocol as published in RFC 4254 has an ambiguity which
    arises if one side of a connection tries to close a channel, while
    the other side simultaneously sends a request within the channel and
    asks for a reply. RFC 4254 leaves it unclear whether the closing
    side should reply to the channel request after having announced its
    intention to close the channel.

    Discussion on the ietf-ssh mailing list in April 2014 formed a clear
    consensus that the right answer is no. However, because of the
    ambiguity in the specification, some SSH servers have implemented
    the other policy; for example, OpenSSH used to until it was fixed.

    Because PuTTY sends channel requests with the want reply'
    flag throughout channels' lifetime (see section 4.26.5), it's
    possible that when connecting to such a server it might receive
    a reply to a request after it thinks the channel has entirely
    closed, and terminate with an error along the lines of
    Received
    SSH2_MSG_CHANNEL_FAILURE for nonexistent channel 256′.

    4.26.13 `Only supports pre-RFC4419 SSH-2 DH GEX’

    The SSH key exchange method that uses Diffie-Hellman group exchange
    was redesigned after its original release, to use a slightly more
    sophisticated setup message. Almost all SSH implementations switched
    over to the new version. (PuTTY was one of the last.) A few old
    servers still only support the old one.

    If this bug is detected, and the client and server negotiate Diffie-
    Hellman group exchange, then PuTTY will send the old message now
    known as SSH2_MSG_KEX_DH_GEX_REQUEST_OLD in place of the new
    SSH2_MSG_KEX_DH_GEX_REQUEST.

    This is an SSH-2-specific bug.

    4.27 The Serial panel

    The Serial panel allows you to configure options that only apply
    when PuTTY is connecting to a local serial line.

    4.27.1 Selecting a serial line to connect to

    The `Serial line to connect to’ box allows you to choose which
    serial line you want PuTTY to talk to, if your computer has more
    than one serial port.

    On Windows, the first serial line is called COM1, and if there is a
    second it is called COM2, and so on.

    This configuration setting is also visible on the Session panel,
    where it replaces the Host Name' box (see section 4.1.1) if the
    connection type is set to
    Serial’.

    4.27.2 Selecting the speed of your serial line

    The Speed' box allows you to choose the speed (orbaud rate’) at
    which to talk to the serial line. Typical values might be 9600,
    19200, 38400 or 57600. Which one you need will depend on the device
    at the other end of the serial cable; consult the manual for that
    device if you are in doubt.

    This configuration setting is also visible on the Session panel,
    where it replaces the Port' box (see section 4.1.1) if the
    connection type is set to
    Serial’.

    4.27.3 Selecting the number of data bits

    The `Data bits’ box allows you to choose how many data bits are
    transmitted in each byte sent or received through the serial line.
    Typical values are 7 or 8.

    4.27.4 Selecting the number of stop bits

    The `Stop bits’ box allows you to choose how many stop bits are used
    in the serial line protocol. Typical values are 1, 1.5 or 2.

    4.27.5 Selecting the serial parity checking scheme

    The `Parity’ box allows you to choose what type of parity checking
    is used on the serial line. The settings are:

    • `None’: no parity bit is sent at all.
  • `Odd’: an extra parity bit is sent alongside each byte, and
    arranged so that the total number of 1 bits is odd.

  • `Even’: an extra parity bit is sent alongside each byte, and
    arranged so that the total number of 1 bits is even.

  • `Mark’: an extra parity bit is sent alongside each byte, and
    always set to 1.

  • `Space’: an extra parity bit is sent alongside each byte, and
    always set to 0.

  • 4.27.6 Selecting the serial flow control scheme

    The `Flow control’ box allows you to choose what type of flow
    control checking is used on the serial line. The settings are:

    • `None’: no flow control is done. Data may be lost if either side
      attempts to send faster than the serial line permits.
  • `XON/XOFF’: flow control is done by sending XON and XOFF
    characters within the data stream.

  • `RTS/CTS’: flow control is done using the RTS and CTS wires on
    the serial line.

  • `DSR/DTR’: flow control is done using the DSR and DTR wires on
    the serial line.

  • 4.28 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 /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 USB stick, you probably want to store
    it on the USB stick.

    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.

    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.

  • Chapter 7: Using the command-line connection tool Plink

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

    Chapter 8: Using public keys for SSH authentication

    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.

    Chapter 10: Common error messages

    This chapter lists a number of common error messages which PuTTY and
    its associated tools can produce, and explains what they mean in
    more detail.

    We do not attempt to list all error messages here: there are many
    which should never occur, and some which should be self-explanatory.
    If you get an error message which is not listed in this chapter and
    which you don’t understand, report it to us as a bug (see appendix
    B) and we will add documentation for it.

    10.1 `The server’s host key is not cached in the registry’

    This error message occurs when PuTTY connects to a new SSH server.
    Every server identifies itself by means of a host key; once PuTTY
    knows the host key for a server, it will be able to detect if a
    malicious attacker redirects your connection to another machine.

    If you see this message, it means that PuTTY has not seen this host
    key before, and has no way of knowing whether it is correct or not.
    You should attempt to verify the host key by other means, such as
    asking the machine’s administrator.

    If you see this message and you know that your installation of PuTTY
    has connected to the same server before, it may have been recently
    upgraded to SSH protocol version 2. SSH protocols 1 and 2 use
    separate host keys, so when you first use SSH-2 with a server you
    have only used SSH-1 with before, you will see this message again.
    You should verify the correctness of the key as before.

    See section 2.2 for more information on host keys.

    10.2 `WARNING – POTENTIAL SECURITY BREACH!’

    This message, followed by `The server’s host key does not match
    the one PuTTY has cached in the registry’, means that PuTTY has
    connected to the SSH server before, knows what its host key should
    be, but has found a different one.

    This may mean that a malicious attacker has replaced your server
    with a different one, or has redirected your network connection
    to their own machine. On the other hand, it may simply mean that
    the administrator of your server has accidentally changed the key
    while upgrading the SSH software; this shouldn’t happen but it is
    unfortunately possible.

    You should contact your server’s administrator and see whether they
    expect the host key to have changed. If so, verify the new host key
    in the same way as you would if it was new.

    See section 2.2 for more information on host keys.

    10.3 `The first cipher supported by the server is … below the
    configured warning threshold’

    This occurs when the SSH server does not offer any ciphers which you
    have configured PuTTY to consider strong enough. By default, PuTTY
    puts up this warning only for single-DES and Arcfour encryption.

    See section 4.20 for more information on this message.

    10.4 `Server sent disconnect message type 2 (protocol error): “Too many
    authentication failures for root”‘

    This message is produced by an OpenSSH (or Sun SSH) server if it
    receives more failed authentication attempts than it is willing to
    tolerate.

    This can easily happen if you are using Pageant and have a large
    number of keys loaded into it, since these servers count each offer
    of a public key as an authentication attempt. This can be worked
    around by specifying the key that’s required for the authentication
    in the PuTTY configuration (see section 4.21.8); PuTTY will ignore
    any other keys Pageant may have, but will ask Pageant to do the
    authentication, so that you don’t have to type your passphrase.

    On the server, this can be worked around by disabling public-key
    authentication or (for Sun SSH only) by increasing MaxAuthTries' insshd_config’.

    10.5 `Out of memory’

    This occurs when PuTTY tries to allocate more memory than the system
    can give it. This may happen for genuine reasons: if the computer
    really has run out of memory, or if you have configured an extremely
    large number of lines of scrollback in your terminal. PuTTY is
    not able to recover from running out of memory; it will terminate
    immediately after giving this error.

    However, this error can also occur when memory is not running out at
    all, because PuTTY receives data in the wrong format. In SSH-2 and
    also in SFTP, the server sends the length of each message before the
    message itself; so PuTTY will receive the length, try to allocate
    space for the message, and then receive the rest of the message.
    If the length PuTTY receives is garbage, it will try to allocate
    a ridiculous amount of memory, and will terminate with an `Out of
    memory’ error.

    This can happen in SSH-2, if PuTTY and the server have not enabled
    encryption in the same way (see question A.7.5 in the FAQ). Some
    versions of OpenSSH have a known problem with this: see question
    A.7.16.

    This can also happen in PSCP or PSFTP, if your login scripts on the
    server generate output: the client program will be expecting an
    SFTP message starting with a length, and if it receives some text
    from your login scripts instead it will try to interpret them as a
    message length. See question A.7.6 for details of this.

    10.6 Internal error',Internal fault’, `Assertion failed’

    Any error beginning with the word `Internal’ should never occur.
    If it does, there is a bug in PuTTY by definition; please see
    appendix B and report it to us.

    Similarly, any error message starting with `Assertion failed’ is a
    bug in PuTTY. Please report it to us, and include the exact text
    from the error message box.

    10.7 Unable to use this private key file',Couldn’t load private key’,
    `Key is of wrong type’

    Various forms of this error are printed in the PuTTY window, or
    written to the PuTTY Event Log (see section 3.1.3.1) when trying
    public-key authentication, or given by Pageant when trying to load a
    private key.

    If you see one of these messages, it often indicates that you’ve
    tried to load a key of an inappropriate type into PuTTY, Plink,
    PSCP, PSFTP, or Pageant.

    You may have specified a key that’s inappropriate for the connection
    you’re making. The SSH-1 and SSH-2 protocols require different
    private key formats, and a SSH-1 key can’t be used for a SSH-2
    connection (or vice versa).

    Alternatively, you may have tried to load an SSH-2 key in a
    foreign' format (OpenSSH or ssh.com) directly into one of the PuTTY
    tools, in which case you need to import it into PuTTY's native
    format (
    *.PPK’) using PuTTYgen – see section 8.2.12.

    10.8 Server refused our public key' orKey refused’

    Various forms of this error are printed in the PuTTY window, or
    written to the PuTTY Event Log (see section 3.1.3.1) when trying
    public-key authentication.

    If you see one of these messages, it means that PuTTY has sent a
    public key to the server and offered to authenticate with it, and
    the server has refused to accept authentication. This usually means
    that the server is not configured to accept this key to authenticate
    this user.

    This is almost certainly not a problem with PuTTY. If you see
    this type of message, the first thing you should do is check your
    server configuration carefully. Common errors include having the
    wrong permissions or ownership set on the public key or the user’s
    home directory on the server. Also, read the PuTTY Event Log; the
    server may have sent diagnostic messages explaining exactly what
    problem it had with your setup.

    Section 8.3 has some hints on server-side public key setup.

    10.9 Access denied',Authentication refused’

    Various forms of this error are printed in the PuTTY window,
    or written to the PuTTY Event Log (see section 3.1.3.1) during
    authentication.

    If you see one of these messages, it means that the server has
    refused all the forms of authentication PuTTY has tried and it has
    no further ideas.

    It may be worth checking the Event Log for diagnostic messages from
    the server giving more detail.

    This error can be caused by buggy SSH-1 servers that fail to cope
    with the various strategies we use for camouflaging passwords in
    transit. Upgrade your server, or use the workarounds described in
    section 4.26.1 and possibly section 4.26.2.

    10.10 `No supported authentication methods available’

    This error indicates that PuTTY has run out of ways to authenticate
    you to an SSH server. This may be because PuTTY has TIS or keyboard-
    interactive authentication disabled, in which case section 4.21.4
    and section 4.21.5.

    10.11 Incorrect CRC received on packet' orIncorrect MAC received on
    packet’

    This error occurs when PuTTY decrypts an SSH packet and its checksum
    is not correct. This probably means something has gone wrong in the
    encryption or decryption process. It’s difficult to tell from this
    error message whether the problem is in the client, in the server,
    or in between.

    In particular, if the network is corrupting data at the TCP level,
    it may only be obvious with cryptographic protocols such as SSH,
    which explicitly check the integrity of the transferred data and
    complain loudly if the checks fail. Corruption of protocols without
    integrity protection (such as HTTP) will manifest in more subtle
    failures (such as misdisplayed text or images in a web browser)
    which may not be noticed.

    A known server problem which can cause this error is described in
    question A.7.16 in the FAQ.

    10.12 `Incoming packet was garbled on decryption’

    This error occurs when PuTTY decrypts an SSH packet and the
    decrypted data makes no sense. This probably means something has
    gone wrong in the encryption or decryption process. It’s difficult
    to tell from this error message whether the problem is in the
    client, in the server, or in between.

    If you get this error, one thing you could try would be to fiddle
    with the setting of Miscomputes SSH-2 encryption keys' (see section
    4.26.7) or
    Ignores SSH-2 maximum packet size’ (see section 4.26.11)
    on the Bugs panel .

    Another known server problem which can cause this error is described
    in question A.7.16 in the FAQ.

    10.13 `PuTTY X11 proxy: various errors

    This family of errors are reported when PuTTY is doing X forwarding.
    They are sent back to the X application running on the SSH server,
    which will usually report the error to the user.

    When PuTTY enables X forwarding (see section 3.4) it creates a
    virtual X display running on the SSH server. This display requires
    authentication to connect to it (this is how PuTTY prevents other
    users on your server machine from connecting through the PuTTY proxy
    to your real X display). PuTTY also sends the server the details it
    needs to enable clients to connect, and the server should put this
    mechanism in place automatically, so your X applications should just
    work.

    A common reason why people see one of these messages is because they
    used SSH to log in as one user (let’s say fred'), and then used
    the Unix
    su’ command to become another user (typically root').
    The original user,
    fred’, has access to the X authentication data
    provided by the SSH server, and can run X applications which are
    forwarded over the SSH connection. However, the second user (`root’)
    does not automatically have the authentication data passed on to it,
    so attempting to run an X application as that user often fails with
    this error.

    If this happens, it is not a problem with PuTTY. You need to
    arrange for your X authentication data to be passed from the user
    you logged in as to the user you used su' to become. How you do
    this depends on your particular system; in fact many modern versions
    of
    su’ do it automatically.

    10.14 `Network error: Software caused connection abort’

    This is a generic error produced by the Windows network code when
    it kills an established connection for some reason. For example, it
    might happen if you pull the network cable out of the back of an
    Ethernet-connected computer, or if Windows has any other similar
    reason to believe the entire network has become unreachable.

    Windows also generates this error if it has given up on the machine
    at the other end of the connection ever responding to it. If the
    network between your client and server goes down and your client
    then tries to send some data, Windows will make several attempts
    to send the data and will then give up and kill the connection. In
    particular, this can occur even if you didn’t type anything, if you
    are using SSH-2 and PuTTY attempts a key re-exchange. (See section
    4.19.2 for more about key re-exchange.)

    (It can also occur if you are using keepalives in your connection.
    Other people have reported that keepalives fix this error for
    them. See section 4.13.1 for a discussion of the pros and cons of
    keepalives.)

    We are not aware of any reason why this error might occur that would
    represent a bug in PuTTY. The problem is between you, your Windows
    system, your network and the remote system.

    10.15 `Network error: Connection reset by peer’

    This error occurs when the machines at each end of a network
    connection lose track of the state of the connection between them.
    For example, you might see it if your SSH server crashes, and
    manages to reboot fully before you next attempt to send data to it.

    However, the most common reason to see this message is if you are
    connecting through a firewall or a NAT router which has timed the
    connection out. See question A.7.10 in the FAQ for more details.
    You may be able to improve the situation by using keepalives; see
    section 4.13.1 for details on this.

    Note that Windows can produce this error in some circumstances
    without seeing a connection reset from the server, for instance if
    the connection to the network is lost.

    10.16 `Network error: Connection refused’

    This error means that the network connection PuTTY tried to make to
    your server was rejected by the server. Usually this happens because
    the server does not provide the service which PuTTY is trying to
    access.

    Check that you are connecting with the correct protocol (SSH, Telnet
    or Rlogin), and check that the port number is correct. If that
    fails, consult the administrator of your server.

    10.17 `Network error: Connection timed out’

    This error means that the network connection PuTTY tried to make to
    your server received no response at all from the server. Usually
    this happens because the server machine is completely isolated from
    the network, or because it is turned off.

    Check that you have correctly entered the host name or IP address
    of your server machine. If that fails, consult the administrator of
    your server.

    Unix also generates this error when it tries to send data down a
    connection and contact with the server has been completely lost
    during a connection. (There is a delay of minutes before Unix gives
    up on receiving a reply from the server.) This can occur if you type
    things into PuTTY while the network is down, but it can also occur
    if PuTTY decides of its own accord to send data: due to a repeat key
    exchange in SSH-2 (see section 4.19.2) or due to keepalives (section
    4.13.1).

    Appendix A: PuTTY FAQ

    A.1 Introduction

    A.1.1 What is PuTTY?

    PuTTY is a client program for the SSH, Telnet and Rlogin network
    protocols.

    These protocols are all used to run a remote session on a computer,
    over a network. PuTTY implements the client end of that session: the
    end at which the session is displayed, rather than the end at which
    it runs.

    In really simple terms: you run PuTTY on a Windows machine, and
    tell it to connect to (for example) a Unix machine. PuTTY opens a
    window. Then, anything you type into that window is sent straight
    to the Unix machine, and everything the Unix machine sends back is
    displayed in the window. So you can work on the Unix machine as if
    you were sitting at its console, while actually sitting somewhere
    else.

    A.2 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, and not in the `Recently fixed’
    section, it probably hasn’t been implemented.

  • A.2.1 Does PuTTY support SSH-2?

    Yes. SSH-2 support has been available in PuTTY since version 0.50.

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

    A.2.2 Does PuTTY support reading OpenSSH or ssh.com SSH-2 private key
    files?

    PuTTY doesn’t support this natively (see the wishlist entry for
    reasons why not), but as of 0.53 PuTTYgen can convert both OpenSSH
    and ssh.com private key files into PuTTY’s format.

    A.2.3 Does PuTTY support SSH-1?

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

    However, the SSH-1 protocol has many weaknesses and is no longer
    considered secure; it should be avoided if at all possible.

    A.2.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’.

    A.2.5 Does PuTTY support storing settings, so I don’t have to change them
    every time?

    Yes, all of PuTTY’s settings can be saved in named session profiles.
    You can also change the default settings that are used for new
    sessions. See section 4.1.2 in the documentation for how to do this.

    A.2.6 Does PuTTY support storing its settings in a disk file?

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

    A.2.7 Does PuTTY support full-screen mode, like a DOS box?

    Yes; this is a new feature in version 0.52.

    A.2.8 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.

    A.2.9 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, or if the Registry is not available, to use the
    -hostkey command-line option. That way, you retain the important
    feature of host key checking: the right key will be accepted and the
    wrong ones will not. Adding an option to turn host key checking off
    completely is the wrong solution and we will not do it.

    If you have host keys available in the common known_hosts' format,
    we have a script called
    kh2reg.py’ to convert them to a Windows
    .REG file, which can be installed ahead of time by double-clicking
    or using `REGEDIT’.

    A.4 Embedding PuTTY in other programs

    A.4.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.

    See also the wishlist entry.

    A.4.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.

    A.4.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.

    A.5 Details of PuTTY’s operation

    A.5.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.

    A.5.2 Where does PuTTY store its data?

    On Windows, PuTTY stores most of its data (saved sessions, SSH host
    keys) in the Registry. The precise location is

    HKEY_CURRENT_USER\Software\SimonTatham\PuTTY

    and within that area, saved sessions are stored under Sessions'
    while host keys are stored under
    SshHostKeys’.

    PuTTY also requires a random number seed file, to improve the
    unpredictability of randomly chosen data needed as part of the
    SSH cryptography. This is stored by default in a file called
    PUTTY.RND'; this is stored by default in theApplication Data’
    directory, or failing that, one of a number of fallback locations.
    If you want to change the location of the random number seed file,
    you can put your chosen pathname in the Registry, at

    HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\RandSeedFile

    You can ask PuTTY to delete all this data; see question A.8.2.

    On Unix, PuTTY stores all of this data in a directory ~/.putty.

    A.6 HOWTO questions

    A.6.1 What login name / password should I use?

    This is not a question you should be asking us.

    PuTTY is a communications tool, for making connections to other
    computers. We maintain the tool; we don’t administer any computers
    that you’re likely to be able to use, in the same way that the
    people who make web browsers aren’t responsible for most of the
    content you can view in them. We cannot help with questions of this
    sort.

    If you know the name of the computer you want to connect to, but
    don’t know what login name or password to use, you should talk to
    whoever administers that computer. If you don’t know who that is,
    see the next question for some possible ways to find out.

    A.6.2 What commands can I type into my PuTTY terminal window?

    Again, this is not a question you should be asking us. You need
    to read the manuals, or ask the administrator, of the computer you
    have connected to
    .

    PuTTY does not process the commands you type into it. It’s only a
    communications tool. It makes a connection to another computer; it
    passes the commands you type to that other computer; and it passes
    the other computer’s responses back to you. Therefore, the precise
    range of commands you can use will not depend on PuTTY, but on what
    kind of computer you have connected to and what software is running
    on it. The PuTTY team cannot help you with that.

    (Think of PuTTY as being a bit like a telephone. If you phone
    somebody up and you don’t know what language to speak to make them
    understand you, it isn’t the telephone company‘s job to find that
    out for you. We just provide the means for you to get in touch;
    making yourself understood is somebody else’s problem.)

    If you are unsure of where to start looking for the administrator
    of your server, a good place to start might be to remember how you
    found out the host name in the PuTTY configuration. If you were
    given that host name by e-mail, for example, you could try asking
    the person who sent you that e-mail. If your company’s IT department
    provided you with ready-made PuTTY saved sessions, then that IT
    department can probably also tell you something about what commands
    you can type during those sessions. But the PuTTY maintainer team
    does not administer any server you are likely to be connecting to,
    and cannot help you with questions of this type.

    A.6.3 How can I make PuTTY start up maximised?

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

    A.6.4 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 -load “mysession”

    (Note: prior to 0.53, the syntax was `@session’. This is now
    deprecated and may be removed at some point.)

    A.6.5 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.6.4.

    A.6.6 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.

    A.6.7 How do I use all PuTTY’s features (public keys, proxying, cipher
    selection, etc.) in PSCP, PSFTP and Plink?

    Most major features (e.g., public keys, port forwarding) are
    available through command line options. See the documentation.

    Not all features are accessible from the command line yet, although
    we’d like to fix this. In the meantime, you can use most of PuTTY’s
    features if you create a PuTTY saved session, and then use the name
    of the saved session on the command line in place of a hostname.
    This works for PSCP, PSFTP and Plink (but don’t expect port
    forwarding in the file transfer applications!).

    A.7 Troubleshooting

    A.7.1 Why do I see `Incorrect MAC received on packet’?

    One possible cause of this that used to be common is a bug in old
    SSH-2 servers distributed by ssh.com. (This is not the only possible
    cause; see section 10.11 in the documentation.) Version 2.3.0 and
    below of their SSH-2 server constructs Message Authentication Codes
    in the wrong way, and expects the client to construct them in the
    same wrong way. PuTTY constructs the MACs correctly by default, and
    hence these old servers will fail to work with it.

    If you are using PuTTY version 0.52 or better, this should work
    automatically: PuTTY should detect the buggy servers from their
    version number announcement, and automatically start to construct
    its MACs in the same incorrect manner as they do, so it will be able
    to work with them.

    If you are using PuTTY version 0.51 or below, you can enable the
    workaround by going to the SSH panel and ticking the box labelled
    `Imitate SSH2 MAC bug’. It’s possible that you might have to do this
    with 0.52 as well, if a buggy server exists that PuTTY doesn’t know
    about.

    In this context MAC stands for Message Authentication Code. It’s a
    cryptographic term, and it has nothing at all to do with Ethernet
    MAC (Media Access Control) addresses.

    A.7.2 Why do I see `Fatal: Protocol error: Expected control record’ in
    PSCP?

    This happens because PSCP was expecting to see data from the server
    that was part of the PSCP protocol exchange, and instead it saw data
    that it couldn’t make any sense of at all.

    This almost always happens because the startup scripts in your
    account on the server machine are generating output. This is
    impossible for PSCP, or any other SCP client, to work around. You
    should never use startup files (.bashrc',.cshrc’ and so on) which
    generate output in non-interactive sessions.

    This is not actually a PuTTY problem. If PSCP fails in this way,
    then all other SCP clients are likely to fail in exactly the same
    way. The problem is at the server end.

    A.7.3 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 theModify’ 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 pressModify’. 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.

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

    A.7.6 When attempting a file transfer, either PSCP or PSFTP says `Out of
    memory’ and dies.

    This is almost always caused by your login scripts on the server
    generating output. PSCP or PSFTP will receive that output when they
    were expecting to see the start of a file transfer protocol, and
    they will attempt to interpret the output as file-transfer protocol.
    This will usually lead to an `out of memory’ error for much the same
    reasons as given in question A.7.5.

    This is a setup problem in your account on your server, not a
    PSCP/PSFTP bug. Your login scripts should never generate output
    during non-interactive sessions; secure file transfer is not the
    only form of remote access that will break if they do.

    On Unix, a simple fix is to ensure that all the parts of your login
    script that might generate output are in .profile' (if you use a
    Bourne shell derivative) or
    .login’ (if you use a C shell). Putting
    them in more general files such as .bashrc' or.cshrc’ is liable
    to lead to problems.

    A.7.7 PSFTP transfers files much slower than PSCP.

    The throughput of PSFTP 0.54 should be much better than 0.53b and
    prior; we’ve added code to the SFTP backend to queue several blocks
    of data rather than waiting for an acknowledgement for each. (The
    SCP backend did not suffer from this performance issue because SCP
    is a much simpler protocol.)

    A.7.8 When I run full-colour applications, I see areas of black space
    where colour ought to be, or vice versa.

    You almost certainly need to change the `Use background colour to
    erase screen’ setting in the Terminal panel. If there is too much
    black space (the commoner situation), you should enable it, while
    if there is too much colour, you should disable it. (See section
    4.3.5.)

    In old versions of PuTTY, this was disabled by default, and would
    not take effect until you reset the terminal (see question A.7.9).
    Since 0.54, it is enabled by default, and changes take effect
    immediately.

    A.7.9 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.

    In versions 0.53b and prior, if you change one of these options in
    the middle of a session, you will find that the change does not
    immediately take effect. It will only take effect once you reset the
    terminal.

    In version 0.54, the behaviour has changed – changes to these
    settings take effect immediately.

    A.7.10 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.13.1 in the documentation for more discussion of this.

    A.7.11 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 create or
    change is

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\
    MSTCP\MaxDataRetries

    (it must be of type DWORD in Win95, or String in Win98/ME). (See MS
    Knowledge Base article 158474 for more information.)

    On Windows NT, 2000, or XP, the registry key to create or change is

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
    Parameters\TcpMaxDataRetransmissions

    and it must be of type DWORD. (See MS Knowledge Base articles 120642
    and 314053 for more information.)

    Set the key’s value to something like 10. This will cause Windows to
    try harder to keep connections alive instead of abandoning them.

    A.7.12 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.7); but writing binary files to your
    terminal is likely to cause various other unpleasant behaviour, so
    this is only a small remedy.

    A.7.13 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.

    A.7.14 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.

    A.7.15 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.

    .END

    Leave a comment

    Filed under Uncategorised