PuTTY使用者手冊（七）

阿新 • • 發佈：2019-01-13

4.16 Telnet面板

Telnet面板允許您配置僅適用於Telnet會話的選項。

4.16.1"處理OLD_ENVIRON歧義"

用於傳遞環境變數的原始Telnet機制沒有得到很好的指定。
在編寫標準(RFC 1408)時，BSD telnet實現已經支援該特性，該標準的目的是描述BSD實現已經在使用的行為。

遺憾的是，標準釋出時出現了一個輸入錯誤，並且錯誤地指定了兩個重要的功能程式碼。
BSD實現沒有改變，標準也沒有得到糾正。
因此，您可能會發現BSD或rfc相容的實現。
這個開關允許您選擇一個PuTTY主張的。

通過釋出第二個標準解決了這個問題，該標準定義了一個新的Telnet機制new_environment，它的行為與原來的old_environment完全相同，但是不受現有實現的限制。
大多數Telnet伺服器現在都支援這一點，這一點是明確的。
只有在您無法將環境變數傳遞給相當舊的伺服器時，才應該需要此功能。

4.16.2被動和主動Telnet協商模式

在Telnet連線中，客戶機和伺服器之間傳遞的資料有兩種型別:實際文字和關於使用哪個Telnet額外特性的協商。

PuTTY可以使用兩種不同的談判策略:

在活動模式下，一旦連線開啟，PuTTY就開始傳送協商。
在被動模式下，PuTTY將等待協商，直到看到來自伺服器的協商。
被動模式的明顯缺點是，如果伺服器也在被動模式下執行，那麼根本不會開始協商。
因此PuTTY預設為活動模式。

然而，有時為了成功地通過某些型別的防火牆和Telnet代理伺服器，需要使用被動模式。
如果您對防火牆有困惑，您可以嘗試啟用被動模式，看看它是否有用。

4.16.3"鍵盤傳送Telnet專用命令"

在Telnet連線中，客戶機和伺服器之間傳遞的資料有兩種型別:實際文字和關於使用哪個Telnet額外特性的協商。

PuTTY可以使用兩種不同的談判策略:

在活動（active）模式下，一旦連線開啟，PuTTY就開始傳送協商。
在被動（passive）模式下，PuTTY將等待協商，直到看到來自伺服器的協商。

被動模式的明顯缺點是，如果伺服器也在被動模式下執行，那麼根本不會開始協商。
因此PuTTY預設為活動模式。

4.16.4 回車鍵傳送Telnet新行而不是^M

如果選中此框，幾個鍵序列的正常操作將被修改:

鍵盤上的退格鍵將傳送Telnet專用退格碼;
Control-C將傳送Telnet專用中斷處理程式碼;
Control-Z將傳送Telnet特殊的掛起程序程式碼。

除非您知道自己在做什麼，否則可能不應該啟用此功能。

4.17 Rlogin面板

Rlogin面板允許您配置僅適用於Rlogin會話的選項。

4.17.1"本地使用者名稱"

Rlogin允許通過伺服器上名為.rhosts的檔案自動(無密碼)登入。
在.rhosts檔案中新增一行程式碼，比如[email protected]，然後在進行Rlogin連線時，客戶機傳輸執行Rlogin客戶機的使用者的使用者名稱。
伺服器根據.rhosts檢查使用者名稱和主機名，如果它們匹配，則不要求輸入密碼。

這隻會起作用，因為Unix系統包含一個安全措施，可以阻止使用者在Rlogin連線中冒充另一個使用者。
Rlogin連線必須來自低於1024的埠號，Unix系統禁止將其用於非特權程序;
因此，當伺服器看到來自低編號埠的連線時，它假設連線的客戶端由一個特權(因此是受信任的)程序持有，因此它相信使用者的宣告。

Windows沒有這個限制:任何使用者都可以從一個低編號的埠發起一個傳出連線。
因此，Rlogin .rhosts機制對於安全地區分Windows機器上的幾個不同使用者是完全無用的。
如果您有一個指向Windows PC的.rhosts條目，您應該假設使用該PC的任何人都可以在Rlogin連線中欺騙您的使用者名稱並訪問伺服器上的帳戶。

“local username”控制元件允許您指定PuTTY應該宣告的使用者名稱，以防它與您的Windows使用者名稱不匹配(或者您沒有費心設定Windows使用者名稱)。

4.18 SSH面板

SSH面板允許您配置只適用於SSH會話的選項。

4.18.1在伺服器上執行特定的命令

在SSH中，您不必在伺服器上執行一般的shell會話。
相反，您可以選擇執行單個特定的命令(例如郵件使用者代理)。
如果您想這樣做，請在“遠端命令”框中輸入命令。

請注意，大多數伺服器在執行該命令後將關閉會話。

4.18.2"完全不啟動shell或命令"

如果勾選此框，PuTTY在連線到遠端伺服器後將不會嘗試執行shell或命令。
如果只使用SSH連線進行埠轉發，並且伺服器上的使用者帳戶不具備執行shell的能力，則可能希望使用此選項。

此特性僅在SSH協議版本2中可用(因為版本1協議假設您總是希望執行shell)。

還可以使用-N命令列選項啟用該特性;
看到3.8.3.13節。

如果您在Plink中使用此功能，您將無法以任何優雅的方式終止Plink程序;
殺死它的唯一方法是按Control-C或從另一個程式傳送一個殺死訊號。

4.18.3啟用壓縮

這支援SSH連線中的資料壓縮:伺服器傳送的資料在傳送之前被壓縮，並在客戶端解壓。
同樣，PuTTY傳送給伺服器的資料首先被壓縮，伺服器在另一端解壓。
這可以幫助最大限度地利用低頻寬連線。

4.18.4"SSH協議版本"

這允許您選擇是使用SSH協議版本2還是舊版本1。

您通常應該將其保留為預設值’ 2 '。
舊的SSH-1協議不僅功能較少，而且不再開發，有許多已知的加密弱點，通常不被認為是安全的。
PuTTY的協議1實現主要是為了相容性而提供的，不再進行增強。

如果伺服器同時提供這兩個版本，請選擇“2”。
如果您有一些只與SSH-1對話的伺服器或裝置，請在這裡選擇“1”，不要將生成的連線視為安全連線。

如果伺服器不匹配您的選擇，PuTTY不會自動退回到協議的其他版本;
相反，它將顯示一條錯誤訊息並中止連線。
這可以防止主動攻擊者將一個預定的SSH-2連線降級到SSH-1。

4.18.5在PuTTY工具之間共享SSH連線

此框中的控制元件允許您配置PuTTY，以便在可能的情況下重用現有SSH連線。

SSH-2協議允許您在同一個SSH連線上執行多個數據通道，這樣您只需登入一次(並且只進行一次昂貴的加密設定)，然後開啟多個終端視窗。

PuTTY的每個例項仍然可以執行一個終端會話,但在這個盒子使用控制元件,您可以配置膩子檢查的另一個例項本身是否已經連線到目標主機,如果有的話,共享例項的SSH連線,而不是另一個新的開始。

要啟用此功能，只需勾選“如果可能的話共享SSH連線”框即可。
然後，每當啟動連線到特定主機的PuTTY會話時，如果現有SSH連線可用，它將嘗試重用該連線。
例如，從系統選單中選擇“Duplicate Session”將在同一主機上啟動另一個會話，如果啟用了共享，那麼它將重用現有的SSH連線。

在使用此模式時，連線到給定伺服器的第一個PuTTY將成為“上游”，這意味著它將管理真正的SSH連線。
所有重用連線的後續PuTTYs都稱為“下行”:它們根本不連線到真正的伺服器，而是通過本地程序間通訊方法連線到上游PuTTY。

要啟用該系統，PuTTY的上游和下游例項都必須啟用共享選項。

因此，在所有下游關閉之前，上游油灰不能終止。
這類似於埠轉發或X11轉發，其中終端會話已經完成的PuTTY仍然保持開啟狀態，以便繼續為轉發的連線提供服務。

如果您需要更詳細地配置這個系統，有兩個額外的複選框允許您指定特定的PuTTY可以作為上游或下游或兩者兼有。
(只有在主“如果可能的話共享SSH連線”框也被選中時，這些框才會生效。)
預設情況下，這兩個框都是勾選的，因此從相同配置啟動的多個PuTTYs將指定其中一個為上游，並共享單個連線;
但是如果因為某些原因你不需要一個特殊的PuTTY配置是一個上游(例如,因為你絕對需要及時關閉)還是下游(例如,因為它需要做自己的身份驗證使用一個特殊的私鑰)然後你可以取消勾選一個或另一個盒子。

在上面的討論中，我一直提到“PuTTY”，但是所有其他建立SSH連線的PuTTY工具也可以使用這種機制。
例如，如果PSCP或PSFTP載入了啟用共享的配置，那麼它可以充當下游，並使用GUI PuTTY例項設定的現有SSH連線。
一個特殊的情況是，PSCP和PSFTP永遠不會作為上行流。

可以使用Plink以程式設計方式測試會話上游是否存在。
見7.2.3.3。

4.19 Kex面板

Kex面板(“金鑰交換”的縮寫)允許您配置與SSH-2金鑰交換相關的選項。

金鑰交換髮生在SSH連線的開始(之後偶爾會發生);
它建立了一個共享祕密，該祕密用作SSH所有安全特性的基礎。
因此，金鑰交換的安全性對於連線的安全性非常重要。

金鑰交換是一個加密密集的過程;
如果客戶機或伺服器是一臺相對較慢的機器，那麼較慢的方法可能需要幾十秒才能完成。

如果連線啟動太慢，或者連線定期掛起，您可能需要嘗試更改這些設定。

如果您不明白這其中的任何含義，那麼就不要管這些設定。

整個面板只與SSH協議版本2相關;
這些設定都不影響sh -1。

4.19.1金鑰交換演算法選擇

PuTTY支援多種SSH-2金鑰交換方法，允許您選擇您喜歡使用的金鑰交換方法;
配置類似於密碼選擇(參見4.21節)。

PuTTY目前支援以下金鑰交換方法:

’ ECDH ':橢圓曲線Diffie-Hellman金鑰交換。
“Group 14”:與著名的2048位組交換Diffie-Hellman金鑰。
“Group 1”:與著名的1024位組交換Diffie-Hellman金鑰。
我們不再建議使用此方法，並且在新安裝中預設不使用此方法;
然而，它可能是非常古老的伺服器軟體所支援的唯一方法。
“Group exchange”:使用這種方法，PuTTY請求伺服器建議使用一個組進行金鑰交換，而不是使用固定的組;
伺服器可以避免已知的弱組，並可能隨著時間的推移建立新的組，而不需要對PuTTY的配置進行任何更改。
如果可能的話，我們建議使用這種方法，而不是使用知名的組。
RSA key exchange:與Diffie-Hellman金鑰交換相比，這在客戶端需要更少的計算工作，在伺服器端需要更少的計算工作。

如果PuTTY發現的第一個演算法低於“warn below here”行，那麼在連線時將看到一個警告框，類似於密碼選擇的警告框(參見4.21節)。

4.19.2重複金鑰交換

如果在連線啟動時協商的會話金鑰使用得太多或時間太長，那麼可以對SSH連線掛載攻擊。
因此，SSH-2協議指定應該每隔一段時間進行一次新的金鑰交換;
這可以由客戶機或伺服器發起。

當重新協商正在進行時，沒有資料可以通過SSH連線，因此它可能看起來“freeze”。
(在事件日誌中記錄重複金鑰交換的發生;見3.1.3.1)
通常使用與連線開始時相同的演算法，但開銷類似。

這些選項控制PuTTY發起重複金鑰交換(“rekey”)的頻率。
您還可以在任何時候從特殊命令選單中強制金鑰交換(參見3.1.3.2節)。

“Max minutes before rekey”指定在啟動rekey之前允許間隔的時間。
如果將其設定為0，那麼PuTTY將不會因為經過的時間而重新鍵入鍵。
sh -2協議規範建議超時時間不超過60分鐘。

您可能需要完全禁用基於時間的rekey，原因與keepalives並不總是有用的原因相同。
如果你預期遭受網路中斷的幾個小時的SSH連線,但實際上並不打算髮送資料,連線在這些時間,然後企圖再續鍵中間的中斷可能會導致連線被拋棄,而如果再續鍵被禁用,那麼連線應原則上生存(沒有干擾的防火牆)。
關於這些問題的更多討論見第4.13.1節;
出於這些目的，rekey具有與keepalives幾乎相同的屬性。
(除了rekeys本身具有加密值之外，所以在決定是否關閉它們時應該記住這一點)注意，SSH伺服器仍然可以發起rekeys。

“rekey之前的最大資料”指定在rekey啟動之前允許向任意方向流動的資料量(以位元組為單位)。
如果將此設定為0,PuTTY將不會因為傳輸的資料而重鍵。
sh -2協議規範建議最大限制為1gb。
除了以位元組為單位指定值外，還可以使用以下簡寫:

’ 1k '指定1 kb(1024位元組)。
1M指定1兆位元組(1024 kb)。
1G指定1G (1024 mb)。
完全禁用基於資料的重鍵不是一個好主意。
在較小程度上，SSH-2協議的完整性和機密性部分依賴於發生在32位資料包序列號包裝之前的重金鑰。
與基於時間的重鍵不同，基於資料的重鍵不會在SSH連線空閒時發生，因此它們不會導致相同的問題。
順便說一句，SSH-1協議的完整性保護甚至比沒有rekey的SSH-2更弱。

4.20主機按鍵面板

Host Keys面板允許您配置與SSH-2主機金鑰管理相關的選項。

主機金鑰用於證明伺服器的身份，並確保伺服器沒有被欺騙(通過中間人攻擊或在網路上完全替換它)。
有關主機鍵的基本介紹，請參見第2.2節。

整個面板只與SSH協議版本2相關;
這些設定都不影響sh -1。

4.20.1主機金鑰型別選擇

PuTTY支援各種SSH-2主機金鑰型別，並允許您選擇更喜歡使用哪一種型別來標識伺服器。
配置類似於密碼選擇(參見4.21節)。

PuTTY目前支援以下主機金鑰型別:

“Ed25519”:Edwards-curve DSA使用扭曲愛德華茲曲線和模量2 ^ 255 - 19所示。
“ECDSA”:使用nist標準橢圓曲線之一的橢圓曲線DSA。
’ DSA ':簡單的DSA使用模冪運算。
RSA:普通RSA演算法。

如果PuTTY已經為伺服器儲存了一個或多個主機鍵，那麼它將更喜歡使用其中一個，即使伺服器的鍵型別在首選項順序中更高。
您可以使用“特殊命令”選單從現有會話中向PuTTY的快取新增這樣的鍵;
3.1.3.2看到部分。

否則，PuTTY將完全根據您在配置中指定的首選項順序選擇鍵型別。

如果PuTTY發現的第一個鍵型別在“warn below here”行下面，那麼在連線時將看到一個警告框，類似於密碼選擇的警告框(參見4.21節)。

4.20.2手動配置主機金鑰

在某些情況下，如果PuTTY的自動主機金鑰管理不能滿足您的需要，您可能需要手動配置PuTTY以接受特定的主機金鑰，或特定的主機金鑰集之一。

您可能希望這樣做的一個原因是，所連線的主機名PuTTY使用迴圈DNS返回多個實際伺服器中的一個，並且它們都有不同的主機金鑰。
在這種情況下，您可能需要配置PuTTY來接受可能伺服器的主機金鑰列表中的任何一個，同時仍然拒絕該列表之外的任何金鑰。

另一個原因是，如果PuTTY的自動主機金鑰管理完全不可用，例如，因為PuTTY(或Plink或PSFTP等)在Windows環境中執行，而無法訪問登錄檔。
在這種情況下，您可能希望使用-hostkey命令列選項來配置預期的主機金鑰;
看到3.8.3.20節。

對於PuTTY的自動主機金鑰管理只是選擇了錯誤的主機名來儲存金鑰的情況，您可能需要考慮設定一個“邏輯主機名”;
4.13.5看到部分。

要通過GUI配置手動主機鍵，請在“手動配置此連線的主機鍵”容器的編輯框中輸入一些描述主機鍵的文字，並按下“Add”按鈕。
文字將出現在“主機金鑰或指紋接受”列表框中。
你可以用“刪除”按鈕再次刪除按鍵。

描述主機金鑰的文字可以採用以下格式之一:

PuTTY的事件日誌和主機金鑰對話方塊中顯示的表單的基於md5的主機金鑰指紋，即由冒號分隔的16個2位十六進位制數字。
一個base64編碼的blob，以OpenSSH的單行公鑰格式描述SSH-2公鑰。
如何以這種格式獲取公鑰取決於伺服器;
在OpenSSH伺服器上，它通常位於/etc/ssh/ssh_host_rsa_key.pub這樣的位置。

如果這個箱子包含至少一個主機金鑰或指紋當PuTTY SSH連線,然後膩子的自動主機金鑰管理是完全繞過:當且僅當,將允許連線的主機金鑰伺服器的關鍵之一在這個盒子上市,和主機金鑰儲存在登錄檔中既不會讀,也不會寫,除非你明確地這樣做。

如果盒子是空的(通常是空的)，那麼PuTTY的自動主機金鑰管理將正常工作。

4.21密碼面板

PuTTY支援各種不同的加密演算法，允許您選擇您喜歡使用的加密演算法。
您可以通過在列表框中上下拖動演算法(或使用上下按鈕移動演算法)來指定首選項順序。
當您建立SSH連線時，PuTTY將從頂部向下搜尋列表，直到找到伺服器支援的演算法，然後使用該演算法。

PuTTY目前支援以下演算法:

ChaCha20-Poly1305，一個組合密碼和MAC(僅適用於sh -2)
AES (Rijndael) - 256、192或128位SDCTR或CBC(僅適用於SSH-2)
arc4 (RC4) - 256或128位流密碼(僅適用於SSH-2)
Blowfish - 256位SDCTR(僅適用於SSH-2)或128位CBC
Trip-DES - 168位SDCTR(僅適用於SSH-2)或CBC
single-DES - 56位CBC (sh -2見下文)

如果PuTTY找到的演算法低於“warn below here”行，連線時將看到一個警告框:

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?

伺服器支援的第一個密碼
低於配置的 single-DES
警告閾值。
您想繼續這個連線嗎?

這將警告您，第一個可用的加密不是非常安全的加密。
通常，你會在你認為安全的加密和你認為不安全的加密之間加上“警告”。
預設情況下，PuTTY提供一個首選項訂單，用於反映安全性和速度方面的合理首選項。

在SSH-2中，加密演算法是針對連線的每個方向獨立協商的，儘管PuTTY不支援首選項順序的單獨配置。
因此，您可能會得到兩個類似於上面的警告，可能使用不同的加密。

在SSH-2協議標準中不建議使用單des，但是有一兩個伺服器實現支援它。
如果啟用“在SSH-2中啟用single-des的遺留使用”選項，PuTTY可以使用單des與這些伺服器進行互操作;
預設情況下，這是禁用的，PuTTY將堅持建議的密碼。

4.22認證面板

Auth面板允許您為SSH會話配置身份驗證選項。

4.22.1"顯示預認證橫幅"

SSH-2伺服器可以為客戶端提供一條訊息，以便在使用者登入之前顯示給潛在使用者;
這有時被稱為身份驗證前的“橫幅”。
通常，這用於提供關於伺服器和法律通知的資訊。

預設情況下，PuTTY在提示輸入密碼或類似憑據之前顯示此訊息(但不幸的是，由於協議設計的性質，在提示輸入登入名之前不會顯示此訊息)。
取消勾選此選項，便可完全抑制旗幟的顯示。

4.22.2"完全繞過認證"

在SSH-2中，原則上可以在不使用SSH的機制向伺服器標識或證明您是誰的情況下建立連線。
例如，SSH伺服器可能更喜歡在資料通道中處理身份驗證，或者根本不需要任何使用者身份驗證。

預設情況下，PuTTY假設伺服器需要身份驗證(我們從未聽說過不需要身份驗證的伺服器)，因此必須以使用者名稱啟動此過程。
如果發現使用者名稱提示無法回答，可以嘗試啟用此選項。
但是，大多數SSH伺服器都會拒絕這一點。

這不是你想要的選項，如果你有一個使用者名稱，只是想要PuTTY記住它;
見第4.14.1節。
如果您試圖設定到主流SSH伺服器的無密碼登入，則可能不會出現這種情況;
根據伺服器的不同，您可能需要公鑰身份驗證(第8章)或GSSAPI身份驗證(第4.23節)。
(這些仍然是身份驗證的形式，即使您不必與它們互動。)

此選項隻影響SSH-2連線。
SSH-1連線總是需要一個身份驗證步驟。

4.22.3"使用Pageant嘗試身份驗證"

如果啟用此選項，那麼PuTTY將查詢Pageant (SSH私鑰儲存代理)並嘗試使用當前持有的任何適當的公鑰Pageant進行身份驗證。

這種行為幾乎總是可取的，因此預設情況下是啟用的。
在極少數情況下，您可能需要關閉它，以便使用密碼等非公鑰方法強制身份驗證。

這個選項也可以使用-noagent命令列選項進行控制。
看3.8.3.9節。

有關Pageant的更多資訊，請參見第9章。

4.22.4"嘗試TIS或加密卡認證"

TIS和加密卡身份驗證(儘管它們的名稱不同)是SSH協議版本1中簡單的挑戰/響應身份驗證的通用形式。
例如，如果您使用的是S/Key一次性密碼，或者您有一個物理安全令牌來生成對身份驗證挑戰的響應，那麼您可能會使用它們。
它們甚至可以用來提示輸入簡單的密碼。

啟用此開關後，如果伺服器願意嘗試這些形式的身份驗證，PuTTY將嘗試這些形式的身份驗證。
您將看到一個質詢字串(每次都可能不同)，必須提供正確的響應才能登入。
如果您的伺服器支援這一點，您應該與系統管理員討論這些挑戰和響應的具體形式。

4.22.5"嘗試鍵盤互動認證"

與TIS身份驗證等效的SSH-2稱為“鍵盤互動”。
它是一種靈活的身份驗證方法，使用任意序列的請求和響應;
因此，它不僅對諸如S/Key這樣的挑戰/響應機制有用，而且還可以用於(例如)在舊密碼過期時向用戶請求新密碼。

PuTTY預設啟用此選項，但提供了一個開關，以便在遇到問題時關閉該選項。

4.22.6"允許代理轉發"

這個選項允許SSH伺服器開啟轉發到您的本地副本的Pageant的連線。
如果你不執行Pageant，這個選項什麼也做不了。

關於Pageant的一般資訊見第9章，關於agent forwarding的資訊見第9.4節。
請注意，啟用此選項涉及安全風險;
有關詳細資訊，請參見9.5節。

4.22.7"允許在SSH-2中嘗試更改使用者名稱"

在SSH-1協議中，身份驗證失敗後不可能更改使用者名稱。
因此，如果您在PuTTY ’ login as: '提示符下輸入錯誤的使用者名稱，您將無法更改它，除非重新啟動PuTTY。

原則上，SSH-2協議允許更改使用者名稱，但不強制要求SSH-2伺服器接受這些更改。
特別是，OpenSSH不接受使用者名稱的更改;
一旦您傳送了一個使用者名稱，它將拒絕作為另一個使用者進行身份驗證的嘗試。
(根據OpenSSH的版本，它可能會悄悄地返回所有登入嘗試的失敗，或者傳送錯誤訊息。)

由於這個原因，PuTTY在預設情況下不會多次提示輸入使用者名稱，以防伺服器抱怨。
如果您知道您的伺服器可以處理它，您可以啟用“允許嘗試更改使用者名稱”選項來修改PuTTY的行為。

4.22.8"用於身份驗證的私鑰檔案"

如果使用公鑰身份驗證，則在此框中輸入私鑰檔案的名稱。
有關SSH中的公鑰身份驗證的資訊，請參見第8章。

此金鑰必須是PuTTY的本機格式(*. ppk)。
如果您有另一種要與PuTTY一起使用的格式的私鑰，請參見第8.2.12節。

您可以使用身份驗證代理盛會，這樣就不需要在這裡顯式地配置金鑰;
見第9章。

如果這裡在執行Pageant時指定了私鑰檔案，PuTTY將首先嚐試要求Pageant使用該金鑰進行身份驗證，並忽略可能具有的任何其他金鑰。
如果失敗，PuTTY將像正常情況一樣請求一個密碼。
在這種情況下，您還可以指定一個公鑰檔案(RFC 4716或OpenSSH格式)，因為這足以標識Pageant的金鑰，但是當然，如果沒有Pageant, PuTTY就不能使用這個檔案本身。

4.23 GSSAPI面板

“認證”面板的“GSSAPI”子面板控制GSSAPI身份驗證的使用。
這是一種將身份驗證交換委託給客戶機機器上其他地方的庫的機制，原則上可以以許多不同的方式進行身份驗證，但實際上通常與Kerberos單點登入協議一起使用，以實現無密碼登入。

GSSAPI僅在SSH-2協議中可用。

GSSAPI子面板上最頂層的控制元件是標記為“嘗試GSSAPI身份驗證”的複選框。
如果禁用此功能，則根本不會嘗試使用GSSAPI，並且該面板的其餘部分未使用。
如果啟用了GSSAPI身份驗證，那麼將嘗試GSSAPI身份驗證，並且(通常)如果您的客戶機上裝載了有效的Kerberos憑證，那麼PuTTY應該能夠自動對支援Kerberos登入的伺服器進行身份驗證。

4.23.1"允許GSSAPI證書授權"

GSSAPI憑據委託是一種將Kerberos(或其他)身份傳遞給SSH伺服器上的會話的機制。
如果啟用此選項，那麼PuTTY不僅能夠自動登入到接受Kerberos憑證的伺服器，還能夠從該伺服器連線到其他支援Kerberos的服務，並像自動一樣使用相同的憑證。

(此選項是SSH代理轉發的Kerberos類似物;
有關這方面的資訊，請參閱第9.4節。)

注意，與SSH代理轉發一樣，這個選項的使用也有安全隱患:您所連線的伺服器的管理員，或者任何破解了該伺服器上的管理員帳戶的人，在連線到支援kerberos的其他服務時，都可以偽造您的身份。
然而，Kerberos站點通常由一箇中心中心執行，因此一臺伺服器的管理員可能已經能夠訪問其他服務;
因此，這通常比SSH代理轉發的風險要小。

4.23.2 GSSAPI庫的首選順序

GSSAPI是一種機制，允許通過同一介面訪問多個身份驗證方法。
因此，您的系統上可能存在多個身份驗證庫，可以使用GSSAPI訪問它們。

PuTTY包含對一些著名的此類庫的本機支援，它將在您的系統上查詢所有這些庫，並使用它找到的任何庫。
如果您的系統中存在多個，並且您需要使用一個特定的系統，那麼您可以調整使用這個首選項列表控制元件進行搜尋的順序。

首選項列表中的一個選項是使用使用者指定的GSSAPI庫。
如果PuTTY的選項列表中沒有按名稱提及要使用的庫，那麼可以在“使用者提供的GSSAPI庫路徑”欄位中輸入它的完整路徑名，並在首選項列表中移動“使用者提供的GSSAPI庫”選項，以確保在選擇其他選項之前先選擇它。

在Windows上，此類庫是副檔名為.dll的檔案，必須以與正在執行的PuTTY可執行檔案相同的方式構建;
如果你有一個32位DLL，你必須執行一個32位版本的PuTTY, 64位也是一樣(見問題a .6.10)。
在Unix上，共享庫通常有一個.so副檔名。

4.24 TTY面板

TTY面板允許您配置遠端偽終端。

4.24.1"不要分配偽終端"

當連線到一個Unix系統,大多數互動式shell會話是執行在一個偽終端,它允許Unix系統假裝跟一個真正的物理終端裝置但允許SSH伺服器捕捉所有的資料來自假裝置並將其傳送回客戶端。

有時候，您可能會發現需要在非偽終端中執行會話。
在油灰中，這通常只對非常專業的用途有用;
雖然在Plink(參見第7章)中，這是通常的工作方式。

4.24.2傳送終端模式

SSH協議允許客戶機為遠端偽終端傳送“終端模式”。
這些通常控制伺服器對本地終端行為的期望。

如果您的伺服器對這些模式沒有合理的預設設定，您可能會發現在這裡更改它們會有所幫助，儘管伺服器可以隨意忽略您的更改。
如果您不理解這些設定，那麼可以忽略這些設定。

(如果沒有請求或分配偽終端，這些設定都不會有任何效果。)

您可以通過在列表中選擇某個模式，選擇其中一個選項並在必要時指定確切的值，然後單擊“Set”來更改該模式。
這些方案的效果如下:

如果選擇了“Auto”選項，PuTTY工具將決定是否向伺服器指定該模式，如果指定，則傳送一個合理的值。
PuTTY將傳送它認為合適的模式(目前只發送退格鍵、擦除和字符集是否為UTF-8、IUTF8的程式碼)。
Unix上的Plink將從本地終端傳播適當的模式(如果有的話)。
如果選擇“Nothing”，則在任何情況下都不會向伺服器指定模式的值。
如果指定了一個值，它將在任何情況下發送到伺服器。
值框的精確語法取決於模式。

預設情況下，所有可用的模式都被列為“Auto”，這在大多數情況下都是正確的。

每個設定的精確效果(如果有的話)取決於伺服器。
它們的名稱來自POSIX和其他Unix系統，它們最有可能對這些系統產生有用的影響。
(一旦登入到這些伺服器，通常可以使用stty命令更改這些設定。)

一些值得注意的模式如下所述;
有關更詳細的解釋，請參見伺服器文件。

擦除是使用者輸入時刪除左邊一個空格的字元。
當設定為“Auto”(預設設定)時，將遵循PuTTY中本地退格鍵的設定(參見4.4.1節)。

這和其他特殊字元指定使用ctrl - C C ^符號,等等。
使用^ < 27 >或^ < 0 x1b >指定一個字元數值,和文字^ ^ ~。
其他非控制字元由它們自己表示。
將框完全留空表示不應該將任何字元分配給指定的函式，儘管並非所有伺服器都支援這一點。

QUIT是一個特殊字元，通常強制結束伺服器上的當前程序(SIGQUIT)。
在許多伺服器預設設定是Ctrl-backslash(^ ),這很容易不小心在許多鍵盤呼叫。
如果這妨礙了你，你可能想把它改成另一個角色或者完全關閉它。
在PuTTY中，可以以多種方式指定ECHO和ICANON等布林模式，如true/false、yes/no和0/1。
(顯式地指定no值與完全不傳送模式是不同的。)
布林模式IUTF8向伺服器傳送終端字符集是否為UTF-8的訊號，用於基本的行編輯;
例如，如果設定不正確，backspace鍵可能會擦除錯誤數量的文字。
但是，簡單地設定這個引數通常不足以讓伺服器使用UTF-8;
POSIX伺服器通常還需要設定語言環境(通過一些與伺服器相關的方法)，儘管許多新的安裝預設為UTF-8。
而且，由於此模式新增到SSH協議的時間比其他模式晚得多，因此許多伺服器(特別是較老的伺服器)不支援通過SSH傳送此模式;
實際上，一些編寫得很差的伺服器反對它的存在，因此您可能會發現需要將其設定為根本不傳送。
當設定為“Auto”時，它遵循本地配置的字符集(參見4.10.1節)。
終端速度配置在其他地方;
看4.14.4節。

4.25 X11面板

X11面板允許您在SSH連線上配置X11的轉發。

如果您的伺服器允許您執行X Window System圖形應用程式，那麼X11轉發允許您安全地讓這些應用程式訪問您的PC上的本地X顯示。

若要啟用X11轉發，請選中“啟用X11轉發”框。
如果你的X顯示器不尋常，你需要在“X顯示器位置”框中輸入它的位置;
如果為空，PuTTY將嘗試在環境中找到一個合理的預設值，如果失敗，則使用主本地顯示(:0)。

有關X11轉發的更多資訊，請參見第3.4節。

4.25.1遠端X11身份驗證

如果使用X11轉發，在SSH伺服器機器上建立的虛擬X伺服器將受到授權資料的保護。
這些資料是由膩子發明和檢驗的。

通常的授權方法被稱為MIT-MAGIC-COOKIE-1。
這是一個簡單的密碼風格的協議:X客戶機向伺服器傳送一些cookie資料，伺服器檢查它是否與真實的cookie匹配。
cookie資料通過未加密的X11連線傳送;
因此，如果允許第三臺機器上的客戶機訪問虛擬X伺服器，那麼cookie將以明文傳送。

PuTTY提供了替代協議XDM-AUTHORIZATION-1。
這是一種經過加密身份驗證的協議:X客戶機每次傳送的資料都是不同的，它依賴於客戶機連線端的IP地址和埠，並且還帶有當前時間戳。
因此，捕獲xdm授權-1字串的竊聽者不能立即將其用於自己的X連線。

PuTTY對XDM-AUTHORIZATION-1的支援是一個實驗性的特性，可能會遇到以下幾個問題:

一些X客戶端可能甚至不支援XDM-AUTHORIZATION-1，所以他們不知道如何處理PuTTY提供的資料。
這種身份驗證機制只適用於SSH-2。
在SSH-1中，SSH伺服器不以機器可讀的格式告訴客戶機轉發連線的源地址，因此無法驗證xdm - authorizsed -1資料。
你會發現這個特性導致一些SSH伺服器問題,不會清理XDM-AUTHORIZATION-1資料會話後,那麼,如果你使用客戶端連線到同一個伺服器,只有MIT-MAGIC-COOKIE-1和分配相同的遠端顯示號碼,你可能會發現,過時的身份驗證資料仍然存在在你的伺服器和你的X連線失敗。

PuTTY的預設設定是mi - magic - cookie -1。
如果你改變了它，你應該確保你知道你在做什麼。

4.25.2 X本地顯示的許可權檔案

如果您正在使用X11轉發，則轉發連線最終指向的本地X伺服器本身可能需要獲得授權。

一些Windows X伺服器不需要這樣做:它們通過更簡單的方式進行授權，比如接受來自本地機器的任何連線，但不接受來自其他任何地方的連線。
但是，如果您的X伺服器確實需要授權，那麼PuTTY需要知道需要什麼授權。

提供此資料的一種方法是，X伺服器將其儲存在與Unix . xauthority檔案格式相同的檔案中。
如果這就是Windows X伺服器的工作方式，那麼可以通過配置這個選項告訴PuTTY在哪裡找到這個檔案。
預設情況下，PuTTY不會嘗試為本地顯示尋找任何授權。

【翻譯不易，轉載請註明出處衡與墨https://blog.csdn.net/le_17_4_6】
未完待續