PuTTY使用者手冊（八）
4.26隧道面板(Tunnels)
隧道面板允許您通過SSH連線配置任意連線型別的隧道。
埠轉發允許您將其他型別的網路連線向下傳輸到SSH會話。
有關埠轉發及其工作原理的一般性討論，請參見第3.5節。
隧道面板中的埠轉發部分顯示了PuTTY在連線到伺服器時嘗試設定的所有埠轉發的列表。
預設情況下不設定埠轉發，因此此列表為空。
新增埠轉發:
設定“本地”或“遠端”單選按鈕之一，這取決於您是想將本地埠轉發到遠端目的地(“本地”)還是將遠端埠轉發到本地目的地(“遠端”)。
或者，如果您希望PuTTY在本地埠上提供本地SOCKS 4/4A/5代理(注意該代理只支援TCP連線;
SSH協議不支援轉發UDP)。
在“源埠”框中輸入源埠號。
對於本地轉接，PuTTY將監聽您的PC的這個埠。
對於遠端轉發，SSH伺服器將監聽遠端機器的這個埠。
注意，大多數伺服器不允許監聽小於1024的埠號。
如果您選擇了“本地”或“遠端”(“Dynamic”不需要這個步驟)，請在“Destination”框中輸入主機名和埠號，並使用冒號分隔。
在源埠上接收的連線將被定向到此目的地。
例如，要連線到POP-3伺服器，
(如果你需要輸入一個IPv6地址，用方括號括起來，例如‘[::1]:2200’。)
點選“新增”按鈕。
您的轉發詳細資訊應該出現在列表框中。
要刪除埠轉發，只需在列表框中選擇其詳細資訊，然後單擊“刪除”按鈕。
在“源埠”框中，還可以選擇輸入要監聽的IP地址，方法是指定(例如)127.0.0.5:79。
有關如何工作及其限制的更多資訊，請參見3.5節。
如果本地系統知道服務名稱，則可以輸入服務名稱來代替埠號。
例如，在“目標”框中，您可以輸入popserver.example.com:pop3。
您可以使用“更改設定”在會話中期修改當前活動的埠轉發集(請參見3.1.3.4節)。
如果在會話中途刪除本地或動態埠轉發，PuTTY將停止偵聽該埠上的連線，因此它可以被另一個程式重用。
如果刪除遠端埠轉發，請注意:
SSH-1協議不包含要求伺服器停止監聽遠端埠的機制。
SSH-2協議確實包含這種機制，但不是所有SSH伺服器都支援它。
(特別是，在3.9之前的任何版本中，OpenSSH都不支援它。)
如果您要求刪除遠端埠轉發，而PuTTY無法使伺服器實際停止偵聽該埠，那麼它將開始拒絕該埠上的傳入連線。
因此，儘管埠不能被另一個程式重用，但至少可以合理地確保伺服器端程式不再能夠在埠轉發端訪問服務。
如果刪除轉發，則使用該轉發建立的任何現有連線將保持開啟狀態。
類似地，對全域性設定(如“本地埠接受來自其他主機的連線”)的更改只對新的轉發生效。
如果您通過SSH轉發的連線本身就是另一個PuTTY副本建立的第二個SSH連線，那麼您可能會發現“邏輯主機名”配置選項對警告PuTTY它應該接收哪個主機金鑰有用。
有關詳細資訊，請參閱4.13.5節。
4.26.1控制轉發埠的可見性
轉發連線的源埠通常不接受來自任何機器的連線，SSH客戶機或伺服器機器本身除外(分別用於本地轉發和遠端轉發)。
隧道面板有一些控制元件可以改變這一點:
- “本地埠接受來自其他主機的連線”選項允許您設定本地到遠端埠轉發，這樣您的客戶端PC以外的機器就可以連線到轉發的埠。
(這也適用於動態襪子轉發。) - “遠端埠執行相同的操作”選項對遠端到本地埠轉發執行相同的操作(以便SSH伺服器以外的機器可以連線到轉發的埠)。
注意，這個特性只在SSH-2協議中可用，並不是所有的SSH-2伺服器都支援它(例如，OpenSSH 3.0不支援)。
4.26.2為轉發埠選擇Internet協議版本
此開關允許您為轉發埠的本地端選擇特定的Internet協議(IPv4或IPv6)。
預設設定為‘Auto’，即:
- 對於本地到遠端埠轉發，PuTTY將偵聽IPv4和IPv6(如果可用)中的傳入連線
- 對於遠端到本地埠轉發，PuTTY將為傳出連線選擇一個合理的協議。
這將覆蓋連接面板上的通用Internet協議版本首選項(參見第4.13.4節)。
注意，一些作業系統可能會偵聽IPv4中的傳入連線，即使您特別要求使用IPv6，因為它們的IPv4和IPv6協議棧是連結在一起的。
顯然，Linux做到了這一點，而Windows沒有。
因此，如果你在Windows上執行PuTTY，你勾選“IPv6”來進行本地或動態埠轉發，它只有通過IPv6連線才能使用;
如果在Linux上也這樣做，也可以在IPv4中使用它。
然而，勾選“Auto”總是會給你一個埠，你可以使用任何一種協議連線到這個埠。
4.27 bug和更多bug面板
不是所有SSH伺服器都能正常工作。
各種現有的伺服器中都有bug，這使得客戶端不可能與它們通訊，除非它知道這個bug並能夠解決它。
由於大多數伺服器在SSH連線的開始就會宣佈它們的軟體版本號，所以PuTTY將嘗試檢測它可以在伺服器中看到的bug，並自動啟用工作區。
然而，有時它會犯錯誤;
如果伺服器被故意配置為隱藏其版本號，或者伺服器是PuTTY的錯誤資料庫不知道的版本，那麼PuTTY將不知道將會出現什麼錯誤。
bug和更多的bug面板(有兩個，因為我們有很多bug相容模式)允許您手動配置PuTTY希望在伺服器中看到的bug。
每個bug可以配置為三種狀態:
- “Off”:PuTTY將假設伺服器沒有這個錯誤。
- “On”:PuTTY將假設伺服器確實存在錯誤。
- “Auto”:PuTTY將使用伺服器的版本號公告來猜測伺服器是否存在錯誤。
4.27.1"對SSH-1的阻塞忽略訊息"
忽略訊息(SSH_MSG_IGNORE)是SSH協議中的訊息，可以在任何時候從客戶機發送到伺服器，或者從伺服器傳送到客戶機。
任何一方在接收到訊息時都必須忽略該訊息。
PuTTY使用ignore訊息將密碼包隱藏在SSH-1中，這樣監聽器就無法知道使用者密碼的長度;
它還使用忽略訊息作為連線保持符(參見4.13.1節)。
如果檢測到此錯誤，PuTTY將停止使用ignore訊息。
這意味著keepalives將停止工作，PuTTY將不得不退回到對SSH-1密碼長度的竊聽的二級防禦。
看到4.27.2節。
如果在與正確的伺服器對話時啟用了此錯誤，會話將成功，但keepalives將不起作用，會話可能比實際更容易受到竊聽者的攻擊。
4.27.2"拒絕所有sh -1密碼偽裝"
當與無法處理忽略訊息的SSH-1伺服器通訊時(請參見第4.27.1節)，PuTTY將試圖通過在密碼包中傳送額外的填充來隱藏使用者密碼的長度。
這在技術上違反了sh -1規範，因此PuTTY只有在不能使用符合標準的忽略訊息作為偽裝時才會這樣做。
從這個意義上說，對於伺服器來說，拒絕接受填充的密碼包並不是一個真正的bug，但是如果伺服器也不能處理忽略訊息，那麼它確實會給生活帶來不便。
如果檢測到這種“錯誤”,PuTTY將假設忽略訊息和填充都不接受,因此它別無選擇,只能傳送使用者的密碼和任何形式的偽裝,這樣一個竊聽使用者能夠輕鬆地找到確切的長度的密碼。
如果在與正確的伺服器對話時啟用了此錯誤，會話將成功，但更容易受到竊聽者的攻擊。
這是一個特定於ssh -1的bug。
sh -2對這種攻擊是安全的。
4.27.3"sh -1 RSA認證阻塞"
一些SSH-1伺服器根本無法處理RSA身份驗證訊息。
如果Pageant正在執行，並且包含任何SSH-1金鑰，PuTTY通常會在返回密碼之前自動嘗試RSA身份驗證，因此這些伺服器在看到RSA嘗試時將崩潰。
如果檢測到此錯誤，PuTTY將直接轉到密碼身份驗證。
如果在與正確的伺服器對話時啟用了此錯誤，會話將成功，但是RSA身份驗證當然是不可能的。
這是一個特定於ssh -1的bug。
4.27.4"對SSH-2忽略訊息的阻塞"
忽略訊息(SSH_MSG_IGNORE)是SSH協議中的訊息，可以在任何時候從客戶機發送到伺服器，或者從伺服器傳送到客戶機。
任何一方在接收到訊息時都必須忽略該訊息。
PuTTY使用SSH-2中的忽略訊息來混淆加密的資料流，使其更難進行加密分析。
它還使用忽略訊息作為連線保持符(參見4.13.1節)。
如果它認為伺服器有這個錯誤，PuTTY將停止使用ignore訊息。
如果在與正確的伺服器對話時啟用了此錯誤，會話將成功，但keepalives將不起作用，並且會話的加密安全性可能不如預期。
4.27.5"阻塞PuTTY的sh -2‘winadj’請求"
PuTTY有時會在通道資料中間向SSH伺服器傳送一個特殊的請求，名為[email protected](參見F.1節)。
此請求的目的是測量到伺服器的往返時間，PuTTY使用該時間來優化其流控制。
伺服器實際上並不需要理解訊息;
它將傳送一條SSH_MSG_CHANNEL_FAILURE訊息，表明它不理解它。
(所有的PuTTY需要的時間計算是某種響應。)
已經知道SSH伺服器被這個訊息以一種方式或另一種方式,因為它有很長的名字,或因為他們無法應付未請求的名字甚至傳送回正確的故障響應的程度,或者因為他們明智地處理它,但填滿和毫無意義的垃圾郵件伺服器的日誌檔案,等等。
因此，PuTTY支援這個bug相容性標誌:如果它認為伺服器有這個bug，它將永遠不會發送它的“[email protected]”請求，也不會發送它的計時資料。
4.27.6"錯誤計算sh -2 HMAC金鑰"
來自ssh.com的SSH伺服器軟體版本2.3.0及以下計算其HMAC訊息身份驗證程式碼的金鑰不正確。
這個問題的一個典型症狀是，PuTTY在會話開始時意外死亡，表示“在包上接收到不正確的MAC”。
如果檢測到這個bug, PuTTY將以與有bug的伺服器相同的方式計算HMAC金鑰，因此通訊仍然是可能的。
如果在與正確的伺服器對話時啟用此錯誤，則通訊將失敗。
這是一個特定於ssh的bug。
4.27.7"錯誤計算sh -2加密金鑰"
來自ssh.com的SSH伺服器軟體的2.0.11以下版本計算會話加密金鑰不正確。
這個問題可能會導致各種錯誤訊息，例如“解密時傳入的資料包被混淆”，甚至可能“記憶體不足”。
如果檢測到此錯誤，PuTTY將以與有錯誤的伺服器相同的方式計算其加密金鑰，因此通訊仍然是可能的。
如果在與正確的伺服器對話時啟用此錯誤，則通訊將失敗。
這是一個特定於ssh的bug。
4.27.8"需要填充sh -2 RSA簽名"
低於3.3版本的OpenSSH要求使用與RSA金鑰模量相同長度的零位元組填充SSH-2 RSA簽名。
sh -2規範規定必須接受未填充的簽名，因此這是一個錯誤。
這個問題的一個典型症狀是，每幾百次嘗試中，PuTTY就會神祕地失敗一次RSA身份驗證，並退回到密碼。
如果檢測到此錯誤，PuTTY將按照OpenSSH所期望的方式填充其簽名。
如果在與正確的伺服器對話時啟用了此錯誤，則很可能不會造成任何損害，因為正確的伺服器通常仍然接受填充簽名，因為它們習慣於與OpenSSH對話。
這是一個特定於ssh的bug。
4.27.9 '在SSH-2 PK auth中誤用會話ID ’
低於2.3版本的OpenSSH要求SSH-2公鑰身份驗證的方式略有不同:客戶機簽名的資料包含以不同方式格式化的會話ID。
如果公鑰身份驗證神祕地不起作用，但是事件日誌(參見3.1.3.1節)認為它成功地傳送了一個簽名，那麼讓這個bug的解決方案看看它是否有用是值得的。
如果檢測到此錯誤，PuTTY將按照OpenSSH所期望的方式對資料進行簽名。
如果在與正確的伺服器對話時啟用此錯誤，則SSH-2公鑰身份驗證將失敗。
這是一個特定於ssh的bug。
4.27.10"sh -2金鑰重換處理不當"
一些SSH伺服器根本無法處理重複金鑰交換，並且會忽略客戶機啟動金鑰交換的嘗試。
由於PuTTY在執行重複金鑰交換時暫停會話，因此這會導致會話在一個小時後掛起(除非您的rekey超時設定不同;
有關rekey的更多資訊，請參見4.19.2節)。
其他非常老的SSH伺服器處理重複金鑰交換的情況甚至更糟，並且在接收到重複金鑰交換請求時斷開連線。
如果檢測到此錯誤，PuTTY將永遠不會發起重複金鑰交換。
如果在與正確的伺服器對話時啟用了此錯誤，會話應該仍然有效，但可能不如您預期的安全。
這是一個特定於ssh的bug。
4.27.11 ‘忽略SSH-2最大資料包大小’
當設定了一個SSH-2通道時，每個端宣佈它願意為該通道接收的資料包的最大大小。
一些伺服器忽略PuTTY的宣告，傳送大於PuTTY願意接受的資料包，導致它報告“傳入的資料包在解密時被混淆”。
如果檢測到此錯誤，PuTTY永遠不會允許通道的流控制視窗增長到足夠大，從而允許伺服器傳送過大的資料包。
如果在與正確的伺服器對話時啟用了此錯誤，會話將正確工作，但下載效能將低於預期。
4.27.12"對封閉渠道的迴應"
RFC 4254中釋出的SSH協議有一個歧義，如果連線的一端試圖關閉通道，而另一端同時在通道中傳送請求並請求應答，就會出現這種歧義。
RFC 4254不清楚關閉方在宣佈關閉通道的意圖後是否應回覆通道請求。
2014年4月關於ietf-ssh郵件列表的討論形成了明確的共識，正確的答案是no。
但是，由於規範的模糊性，一些SSH伺服器實現了另一種策略;
例如，OpenSSH在修復之前一直是這樣。
因為PuTTY傳送通道請求想要回復的旗在渠道的一生(參見4.27.5節),這是可能的,當連線到這樣的伺服器可能會收到一個回覆一個請求後,認為通道已經完全關閉,並終止與一個錯誤的收到SSH2_MSG_CHANNEL_FAILURE 256不存在的通道”。
4.27.13"僅支援pre-RFC4419 sh -2 DH GEX"
使用Diffie-Hellman組exchange的SSH金鑰交換方法在其原始版本之後進行了重新設計，以使用稍微複雜一些的設定訊息。
幾乎所有SSH實現都切換到新版本。
(PuTTY是最後一個。)
一些舊伺服器仍然只支援舊伺服器。
如果檢測到此錯誤，並且客戶機和伺服器協商difffie - hellman組交換，那麼PuTTY將傳送現在稱為SSH2_MSG_KEX_DH_GEX_REQUEST_OLD的舊訊息，以替代新的SSH2_MSG_KEX_DH_GEX_REQUEST。
這是一個特定於ssh的bug。
4.28序列面板(serial)
序列面板允許您配置僅適用於PuTTY連線到本地序列線路時的選項。
4.28.1選擇要連線的序列線路
如果您的計算機有多個串列埠，“串列埠連線”框允許您選擇要與膩子對話的串列埠。
在Windows上，第一個序列行稱為COM1，如果有第二個序列行，則稱為COM2，以此類推。
在會話面板上也可以看到這個配置設定，如果連線型別設定為“Serial”，它將替換“Host Name”框(參見4.1.1節)。
4.28.2選擇序列線路的速度
“速度”框允許您選擇與序列線通訊的速度(或“波特率”)。
典型值可能是9600、19200、38400或57600。
你需要哪一個將取決於裝置在序列電纜的另一端;
如果您有疑問，請查閱該裝置的使用手冊。
在會話面板上也可以看到這個配置設定，如果連線型別設定為“Serial”，它將替換“Port”框(參見4.1.1節)。
4.28.3選擇資料位的個數
“資料位”框允許您選擇在通過序列行傳送或接收的每個位元組中傳輸多少資料位。
典型值是7或8。
4.28.4選擇停止位的個數
“停止位”框允許您選擇在序列行協議中使用多少停止位。
典型值是1、1.5或2。
4.28.5選擇序列奇偶校驗方案
“奇偶校驗”(Parity)框允許您選擇在序列行上使用哪種型別的奇偶校驗。
設定:
- “None”:根本沒有奇偶校驗位被髮送。
- ‘Odd’:一個額外的奇偶校驗位與每個位元組一起傳送，並安排，使1位的總數是奇數。
- ‘Even’:在每個位元組旁邊傳送一個額外的奇偶校驗位，並安排使1位的總數為偶數。
- “Mark”:在每個位元組旁邊傳送一個額外的奇偶校驗位，並且總是設定為1。
- “Space”:在每個位元組旁邊傳送一個額外的奇偶校驗位，並且總是設定為0。
4.28.6選擇串列埠流量控制方案
“流控制”（Flow)框允許您選擇在序列行上使用哪種型別的流控制檢查。
設定:
- “None”:不進行流控制。
如果任何一方試圖傳送的資料比序列線路允許的速度快，那麼資料可能會丟失。 - ’ XON/XOFF ':流控制是通過在資料流中傳送XON和XOFF字元來完成的。
- “RTS/CTS”:流控制是使用串列埠線上的RTS和CTS線來完成的。
- “DSR/DTR”:通過串列埠線上的DSR和DTR線進行流量控制。
4.29在檔案中儲存配置
PuTTY目前不支援將其配置儲存在檔案而不是登錄檔中。
但是，您可以使用幾個批處理檔案來解決這個問題。
您將需要一個名為PUTTY.BAT的檔案，將檔案的內容匯入登錄檔，然後執行PuTTY，將登錄檔的內容匯出迴文件，並刪除登錄檔項。
這都可以使用Regedit命令列選項來完成，所以這是全自動的。
這是你在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
這個批處理檔案需要兩個輔助檔案:PUTTYRND.REG為PuTTY設定了初始安全位置。
還有PUTTY.RND隨機種子檔案
一旦登錄檔成功儲存迴文件，PUTTYDEL.REG將銷燬登錄檔中的所有內容。
PUTTYDEL.REG:
REGEDIT4
[-HKEY_CURRENT_USER\Software\SimonTatham\PuTTY]
這是一個PUTTYRND.REG 檔案的例子:
REGEDIT4
[HKEY_CURRENT_USER\Software\SimonTatham\PuTTY]
"RandSeedFile"="a:\\putty.rnd"
你應該更換一個:\putty.rand 包含您想要儲存隨機數資料的位置。
如果你的目標是隨身攜帶一個有PuTTY和它的設定的u盤，你可能想要把它儲存在u盤上。
【翻譯不易，轉載請註明出處 衡與墨https://blog.csdn.net/le_17_4_6】
未完待續