1. SSH協(xié)議從密碼到密鑰的信任建立之旅當(dāng)你需要遠(yuǎn)程管理一臺(tái)服務(wù)器或者安全地傳輸文件時(shí)SSHSecure Shell幾乎是唯一的選擇。它就像一個(gè)加密的隧道把你在本地敲擊的每一個(gè)字符、傳輸?shù)拿恳粋€(gè)字節(jié)都嚴(yán)嚴(yán)實(shí)實(shí)地包裹起來(lái)防止任何窺探。但你是否想過(guò)這個(gè)看似簡(jiǎn)單的“連接”動(dòng)作背后究竟發(fā)生了多少輪復(fù)雜的“握手”和“協(xié)商”為什么第一次連接時(shí)會(huì)彈出一個(gè)警告公鑰和私鑰又是如何協(xié)同工作讓你實(shí)現(xiàn)免密登錄的理解SSH的完整流程絕不僅僅是滿足技術(shù)好奇心。當(dāng)連接超時(shí)、認(rèn)證失敗、或者速度異常時(shí)清晰的流程認(rèn)知能讓你像偵探一樣快速定位問(wèn)題究竟出在“握手”、“密鑰交換”、“認(rèn)證”還是“會(huì)話建立”的哪一個(gè)環(huán)節(jié)。而Wireshark這個(gè)網(wǎng)絡(luò)世界的“顯微鏡”則能將協(xié)議層抽象的交互還原成一個(gè)個(gè)看得見(jiàn)、摸得著的網(wǎng)絡(luò)數(shù)據(jù)包讓理論照進(jìn)現(xiàn)實(shí)。今天我們就拋開(kāi)枯燥的RFC文檔以一次完整的SSH連接為線索親手用Wireshark抓取并剖析每一個(gè)數(shù)據(jù)包。我會(huì)帶你走一遍從TCP三次握手開(kāi)始到最終打開(kāi)一個(gè)遠(yuǎn)程Shell的完整旅程。你會(huì)看到加密是如何層層加碼的認(rèn)證是如何步步為營(yíng)的以及那些常見(jiàn)的連接錯(cuò)誤在數(shù)據(jù)包層面究竟長(zhǎng)什么樣。無(wú)論你是運(yùn)維工程師、開(kāi)發(fā)人員還是網(wǎng)絡(luò)安全愛(ài)好者這次深入的抓包分析都將讓你對(duì)SSH的理解提升一個(gè)維度。2. 實(shí)驗(yàn)環(huán)境搭建與Wireshark抓包準(zhǔn)備在開(kāi)始解剖SSH協(xié)議之前我們得先準(zhǔn)備好手術(shù)臺(tái)和顯微鏡。一個(gè)可控的實(shí)驗(yàn)環(huán)境是成功抓包分析的前提它能避免公網(wǎng)復(fù)雜環(huán)境的干擾讓我們專注于協(xié)議本身。2.1 構(gòu)建本地SSH實(shí)驗(yàn)環(huán)境最干凈、最理想的實(shí)驗(yàn)環(huán)境是在本地用虛擬機(jī)搭建。我推薦使用VirtualBox或VMware創(chuàng)建兩臺(tái)Linux虛擬機(jī)如Ubuntu Server一臺(tái)作為客戶端一臺(tái)作為服務(wù)器。將它們的網(wǎng)絡(luò)模式設(shè)置為“僅主機(jī)Host-Only”網(wǎng)絡(luò)這樣所有流量都只在你的物理主機(jī)內(nèi)部循環(huán)不會(huì)被路由到外部網(wǎng)絡(luò)也方便Wireshark在物理主機(jī)上抓取到所有流量。在服務(wù)器虛擬機(jī)上我們需要確保SSH服務(wù)正在運(yùn)行。通常OpenSSH server默認(rèn)可能沒(méi)有安裝。你可以通過(guò)以下命令來(lái)安裝和啟動(dòng)它sudo apt update sudo apt install openssh-server -y sudo systemctl enable ssh sudo systemctl start ssh安裝完成后使用sudo systemctl status ssh命令檢查服務(wù)狀態(tài)確認(rèn)其處于“active (running)”狀態(tài)。默認(rèn)情況下SSH服務(wù)監(jiān)聽(tīng)在22號(hào)端口。在客戶端虛擬機(jī)上只需要安裝SSH客戶端即可通常它已經(jīng)包含在openssh-client包中。你可以通過(guò)ssh -V命令來(lái)檢查客戶端版本。2.2 Wireshark配置與抓包過(guò)濾器技巧接下來(lái)是關(guān)鍵的抓包工具——Wireshark。請(qǐng)務(wù)必從官網(wǎng)下載安裝以保證功能的完整性。安裝后啟動(dòng)Wireshark你會(huì)看到一系列網(wǎng)絡(luò)接口列表。在我們的“僅主機(jī)網(wǎng)絡(luò)”環(huán)境下你需要選擇對(duì)應(yīng)VirtualBox或VMware創(chuàng)建的虛擬網(wǎng)卡名稱可能類似“VirtualBox Host-Only Ethernet Adapter”。直接開(kāi)始抓包會(huì)捕獲到海量的無(wú)關(guān)數(shù)據(jù)包比如ARP廣播、DHCP請(qǐng)求等。為了精準(zhǔn)捕獲SSH流量我們必須使用捕獲過(guò)濾器。在開(kāi)始抓包前在捕獲過(guò)濾器的輸入框中填入tcp port 22。這個(gè)過(guò)濾器告訴Wireshark“只抓取源端口或目標(biāo)端口是22的TCP數(shù)據(jù)包?！币?yàn)镾SH默認(rèn)使用22端口這樣能極大減少噪音。注意這里用的是“捕獲過(guò)濾器”它在抓包時(shí)生效直接丟棄不匹配的數(shù)據(jù)包可以節(jié)省系統(tǒng)資源。而“顯示過(guò)濾器”是在抓包后用來(lái)篩選查看的兩者語(yǔ)法相似但作用階段不同不要混淆。點(diǎn)擊開(kāi)始抓包后窗口可能暫時(shí)一片空白。這時(shí)從你的客戶端虛擬機(jī)執(zhí)行一個(gè)簡(jiǎn)單的連接測(cè)試命令ssh 服務(wù)器IP地址。如果這是首次連接會(huì)提示你確認(rèn)服務(wù)器指紋輸入yes后會(huì)提示你輸入密碼。我們先輸入錯(cuò)誤的密碼讓認(rèn)證失敗然后關(guān)閉連接。這個(gè)簡(jiǎn)單的操作會(huì)觸發(fā)SSH協(xié)議從連接到失敗退出的完整流程非常適合我們分析。2.3 首次連接的關(guān)鍵數(shù)據(jù)包保存在客戶端完成一次失敗的連接嘗試后回到Wireshark點(diǎn)擊停止抓包。你應(yīng)該能看到一系列數(shù)據(jù)包。立即將抓包結(jié)果保存為一個(gè)文件例如ssh_analysis.pcapng。這是一個(gè)好習(xí)慣因?yàn)閃ireshark的默認(rèn)內(nèi)存緩沖區(qū)可能有限保存文件可以確保我們后續(xù)能從容地、反復(fù)地分析這些數(shù)據(jù)?，F(xiàn)在我們有了“手術(shù)樣本”。在開(kāi)始分析前我建議在Wireshark的顯示過(guò)濾器欄輸入ssh這樣會(huì)只顯示SSH協(xié)議的數(shù)據(jù)包界面會(huì)更加清晰。準(zhǔn)備工作就緒讓我們正式進(jìn)入SSH協(xié)議的核心流程。3. 逐層拆解一次SSH連接的完整報(bào)文對(duì)話現(xiàn)在我們面對(duì)Wireshark窗口中按時(shí)間順序排列的數(shù)據(jù)包就像拿到了一部電影的原始膠片。我們的任務(wù)是把它們按場(chǎng)景剪輯理解每一段對(duì)話的意義。一個(gè)完整的SSH連接大致可以分為四個(gè)階段TCP連接建立、SSH協(xié)議版本協(xié)商、密鑰交換與算法協(xié)商、用戶認(rèn)證。讓我們跟隨數(shù)據(jù)包的腳步一步步拆解。3.1 基石TCP三次握手與連接建立任何基于TCP的應(yīng)用層協(xié)議都始于一次經(jīng)典的三次握手。SSH也不例外。在你的抓包文件中找到最開(kāi)始的三個(gè)數(shù)據(jù)包它們通常標(biāo)記為[SYN],[SYN, ACK],[ACK]。數(shù)據(jù)包1客戶端 - 服務(wù)器客戶端發(fā)送一個(gè)TCP報(bào)文其標(biāo)志位SYNSynchronize Sequence Numbers被置為1序列號(hào)Seq為一個(gè)隨機(jī)數(shù)比如0。這好比客戶端對(duì)服務(wù)器說(shuō)“嗨我想和你建立連接我的初始序列號(hào)是X?！睌?shù)據(jù)包2服務(wù)器 - 客戶端服務(wù)器回應(yīng)一個(gè)報(bào)文標(biāo)志位SYN和ACK同時(shí)置1。它確認(rèn)ACK了客戶端的序列號(hào)Ack 客戶端的Seq1并發(fā)出自己的初始序列號(hào)Seq為另一個(gè)隨機(jī)數(shù)。這相當(dāng)于服務(wù)器回答“收到你的請(qǐng)求了ACK我同意連接我的初始序列號(hào)是Y。”數(shù)據(jù)包3客戶端 - 服務(wù)器客戶端再發(fā)送一個(gè)ACK報(bào)文確認(rèn)服務(wù)器的序列號(hào)Ack 服務(wù)器的Seq1。至此雙向通信通道建立完成。客戶端說(shuō)“好的收到你的同意了我們可以開(kāi)始通話了?！边@個(gè)階段在Wireshark的Info列會(huì)顯示為“TCP 3-Way Handshake”。如果這一步失敗可能是網(wǎng)絡(luò)不通、防火墻攔截了22端口或者服務(wù)器SSH服務(wù)未啟動(dòng)。在分析SSH問(wèn)題時(shí)首先確認(rèn)TCP握手是否成功是排除網(wǎng)絡(luò)層故障的第一步。3.2 握手伊始SSH協(xié)議版本協(xié)商TCP連接建立后應(yīng)用層的SSH對(duì)話正式開(kāi)始。緊接著三次握手你應(yīng)該會(huì)看到客戶端發(fā)出第一個(gè)實(shí)際攜帶SSH協(xié)議內(nèi)容的數(shù)據(jù)包。數(shù)據(jù)包4客戶端 - 服務(wù)器客戶端向服務(wù)器發(fā)送一個(gè)明文報(bào)文。在Wireshark中展開(kāi)這個(gè)數(shù)據(jù)包的“Secure Shell Layer”你會(huì)看到類似這樣的內(nèi)容SSH Version: SSH-2.0-OpenSSH_8.9p1這是一個(gè)明文字符串宣告客戶端支持的SSH協(xié)議最高版本是2.0并且客戶端軟件是OpenSSH 8.9p1。SSH協(xié)議版本協(xié)商非常簡(jiǎn)單粗暴雙方都發(fā)出自己支持的版本號(hào)如果兼容通常都支持2.0則使用兩者中較低的版本實(shí)際上現(xiàn)在基本都固定用2.0。早期的SSH-1.0協(xié)議存在設(shè)計(jì)缺陷現(xiàn)已基本廢棄。數(shù)據(jù)包5服務(wù)器 - 客戶端服務(wù)器回應(yīng)自己的版本信息例如SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6。這表示服務(wù)器也支持SSH-2.0。這個(gè)交換是明文的沒(méi)有加密。因此在Wireshark里我們可以直接看到。版本協(xié)商成功后雙方才會(huì)進(jìn)入下一個(gè)更復(fù)雜的階段。3.3 核心機(jī)密密鑰交換與算法協(xié)商這是SSH協(xié)議最精妙、最核心的部分目的是在一個(gè)不安全的網(wǎng)絡(luò)環(huán)境中安全地協(xié)商出一個(gè)后續(xù)用于加密通信的“會(huì)話密鑰”。這個(gè)過(guò)程利用了Diffie-Hellman密鑰交換算法。算法列表交換在版本協(xié)商后客戶端和服務(wù)器會(huì)互相發(fā)送一個(gè)“密鑰交換初始化”報(bào)文SSH_MSG_KEXINIT。在Wireshark中這些報(bào)文內(nèi)容看起來(lái)是一長(zhǎng)串用逗號(hào)分隔的算法名稱。它們各自列出了自己支持的密鑰交換算法如curve25519-sha256,ecdh-sha2-nistp256,diffie-hellman-group14-sha1等。用于生成共享秘密。服務(wù)器主機(jī)密鑰算法如ssh-ed25519,ecdsa-sha2-nistp256,rsa-sha2-256等。用于服務(wù)器身份認(rèn)證。加密算法如chacha20-poly1305openssh.com,aes128-gcm,aes256-cbc等。用于加密后續(xù)傳輸?shù)臄?shù)據(jù)。消息認(rèn)證碼算法如umac-64-etmopenssh.com,hmac-sha2-256等。用于驗(yàn)證數(shù)據(jù)完整性。壓縮算法通常是none表示不壓縮。雙方會(huì)從對(duì)方的列表中選擇自己列表中也存在的、且優(yōu)先級(jí)最高的算法。例如客戶端列表是A, B, C服務(wù)器列表是C, B, D那么雙方最終會(huì)選擇B因?yàn)锳不在服務(wù)器列表C的優(yōu)先級(jí)在客戶端可能低于B。Diffie-Hellman密鑰交換算法選定后假設(shè)是diffie-hellman-group14-sha1雙方開(kāi)始執(zhí)行DH交換。服務(wù)器會(huì)發(fā)送一個(gè)包含大素?cái)?shù)p、生成元g、以及服務(wù)器公鑰e的報(bào)文。客戶端收到后生成自己的公鑰f發(fā)送給服務(wù)器。 這個(gè)過(guò)程的精妙之處在于雙方利用對(duì)方的公鑰和自己的私鑰可以獨(dú)立計(jì)算出一個(gè)相同的“共享秘密”Shared Secret。而竊聽(tīng)者即使截獲了網(wǎng)絡(luò)上傳輸?shù)膒,g,e,f在有限時(shí)間內(nèi)也無(wú)法計(jì)算出這個(gè)共享秘密基于離散對(duì)數(shù)難題。生成會(huì)話密鑰與服務(wù)器認(rèn)證利用這個(gè)“共享秘密”以及交換過(guò)程中所有報(bào)文的哈希值雙方可以派生出一組對(duì)稱密鑰包括初始加密密鑰IV、數(shù)據(jù)加密密鑰、完整性驗(yàn)證密鑰等。同時(shí)服務(wù)器會(huì)用自己的主機(jī)私鑰對(duì)本次交換過(guò)程中所有關(guān)鍵數(shù)據(jù)進(jìn)行簽名并將簽名和它的主機(jī)公鑰一起發(fā)送給客戶端。這是關(guān)鍵一步客戶端此時(shí)已經(jīng)有了服務(wù)器的公鑰可能是第一次見(jiàn)。它會(huì)用這個(gè)公鑰去驗(yàn)證簽名。如果驗(yàn)證通過(guò)就證明了兩個(gè)事實(shí)第一與我通信的對(duì)方確實(shí)擁有與這個(gè)公鑰配對(duì)的私鑰第二剛才的密鑰交換過(guò)程沒(méi)有被篡改。至此客戶端完成了對(duì)服務(wù)器身份的驗(yàn)證。這也是為什么第一次連接時(shí)客戶端會(huì)提示你“無(wú)法確認(rèn)主機(jī)真實(shí)性”并顯示一個(gè)公鑰指紋通常是公鑰的MD5或SHA256哈希值讓你人工核對(duì)。你確認(rèn)了這個(gè)公鑰就被保存在客戶端的~/.ssh/known_hosts文件里下次連接就不會(huì)再警告了。這個(gè)階段結(jié)束后后續(xù)所有的通信都將使用剛剛協(xié)商出的對(duì)稱密鑰進(jìn)行加密。你在Wireshark里會(huì)看到之后的SSH協(xié)議數(shù)據(jù)包的“Encrypted packet”部分變成了亂碼無(wú)法直接解讀。3.4 最后關(guān)卡用戶認(rèn)證階段服務(wù)器身份驗(yàn)證通過(guò)后接下來(lái)就是客戶端向服務(wù)器證明“我是誰(shuí)”。SSH支持多種認(rèn)證方式最常見(jiàn)的是密碼認(rèn)證和公鑰認(rèn)證。密碼認(rèn)證流程客戶端發(fā)送一個(gè)認(rèn)證請(qǐng)求SSH_MSG_USERAUTH_REQUEST聲明想使用password認(rèn)證方式并帶上用戶名。服務(wù)器回復(fù)一個(gè)認(rèn)證挑戰(zhàn)可能直接接受或要求進(jìn)行PAM交互等。在我們的簡(jiǎn)單場(chǎng)景中服務(wù)器通常會(huì)直接進(jìn)入下一步。客戶端再次發(fā)送請(qǐng)求這次包含了加密后的密碼。注意密碼是在已經(jīng)加密的隧道中傳輸?shù)乃訵ireshark看到的是加密后的數(shù)據(jù)非常安全。服務(wù)器驗(yàn)證密碼。如果正確回復(fù)認(rèn)證成功SSH_MSG_USERAUTH_SUCCESS如果錯(cuò)誤回復(fù)認(rèn)證失敗SSH_MSG_USERAUTH_FAILURE并可能告知還允許哪些認(rèn)證方式。公鑰認(rèn)證流程免密登錄客戶端發(fā)送認(rèn)證請(qǐng)求聲明使用publickey方式并附帶用于認(rèn)證的公鑰。服務(wù)器檢查該公鑰是否存在于相應(yīng)用戶的~/.ssh/authorized_keys文件中。如果存在服務(wù)器生成一個(gè)隨機(jī)挑戰(zhàn)challenge。服務(wù)器將這個(gè)挑戰(zhàn)用客戶端提供的公鑰加密后發(fā)送給客戶端?？蛻舳擞米约旱乃借€解密這個(gè)挑戰(zhàn)然后對(duì)挑戰(zhàn)進(jìn)行某種運(yùn)算如簽名將結(jié)果發(fā)回服務(wù)器。服務(wù)器用存儲(chǔ)的公鑰驗(yàn)證這個(gè)簽名。驗(yàn)證通過(guò)則認(rèn)證成功。公鑰認(rèn)證的安全性更高因?yàn)樗恍枰诰W(wǎng)絡(luò)上傳送密碼即使是加密的并且可以抵抗暴力破解。在Wireshark中你只能看到認(rèn)證方式的聲明和加密后的挑戰(zhàn)/響應(yīng)數(shù)據(jù)流無(wú)法看到私鑰或密碼的任何信息。4. 從理論到實(shí)戰(zhàn)Wireshark深度排查常見(jiàn)SSH問(wèn)題掌握了正常流程Wireshark就從一個(gè)觀察工具變成了強(qiáng)大的排錯(cuò)利器。很多棘手的SSH連接問(wèn)題在數(shù)據(jù)包層面都會(huì)留下清晰的蛛絲馬跡。我們來(lái)看幾個(gè)典型場(chǎng)景。4.1 案例診斷連接超時(shí)與握手失敗癥狀客戶端執(zhí)行ssh userhost后長(zhǎng)時(shí)間掛起最終報(bào)錯(cuò)“Connection timed out”。排查思路檢查TCP握手在Wireshark中過(guò)濾tcp.port 22。觀察是否有客戶端發(fā)出的[SYN]包。無(wú)[SYN]包可能是客戶端防火墻阻止了出站連接或者DNS解析失敗你用了主機(jī)名而非IP。檢查客戶端防火墻規(guī)則和/etc/hosts文件。有[SYN]包但無(wú)回應(yīng)服務(wù)器沒(méi)有返回[SYN, ACK]。這強(qiáng)烈指向網(wǎng)絡(luò)路由問(wèn)題或服務(wù)器端防火墻如iptables, firewalld丟棄了22端口的入站請(qǐng)求。你可以在服務(wù)器上使用sudo iptables -L -n或sudo firewall-cmd --list-all來(lái)檢查規(guī)則。有完整的TCP三次握手那么問(wèn)題出在TCP之上。繼續(xù)看后續(xù)是否有SSH版本協(xié)商包。檢查SSH版本協(xié)商如果TCP握手成功但緊接著沒(méi)有SSH版本字符串的交換連接就斷了?？赡艿脑虬ǚ?wù)器SSH服務(wù)未運(yùn)行在服務(wù)器上執(zhí)行sudo systemctl status sshd確認(rèn)。服務(wù)器監(jiān)聽(tīng)地址SSH服務(wù)可能只綁定在127.0.0.1本地回環(huán)而不是0.0.0.0所有接口。檢查/etc/ssh/sshd_config中的ListenAddress配置。中間設(shè)備干擾有些網(wǎng)絡(luò)設(shè)備如某些防火墻、入侵檢測(cè)系統(tǒng)可能會(huì)異常斷開(kāi)空閑的TCP連接或者錯(cuò)誤地處理了SSH協(xié)議的初始報(bào)文。4.2 案例診斷認(rèn)證反復(fù)失敗與算法不匹配癥狀連接能建立但總是在輸入密碼或使用密鑰后認(rèn)證失敗日志提示“Permission denied”或“Authentication failed”。排查思路觀察認(rèn)證階段報(bào)文在Wireshark中跟隨TCP流右鍵數(shù)據(jù)包 - Follow - TCP Stream可以更清晰地看到文本交互對(duì)于版本協(xié)商等明文部分。關(guān)注服務(wù)器返回的SSH_MSG_USERAUTH_FAILURE報(bào)文。它里面會(huì)包含一個(gè)partial success標(biāo)志和auth that can continue字段。如果auth that can continue字段包含publickey說(shuō)明服務(wù)器期望公鑰認(rèn)證但你可能未提供或提供了錯(cuò)誤的密鑰。檢查客戶端的-i參數(shù)或~/.ssh/id_rsa等密鑰文件。如果包含password說(shuō)明密碼認(rèn)證可用但你的密碼錯(cuò)了。注意服務(wù)器可能配置了禁止密碼登錄PasswordAuthentication no此時(shí)這個(gè)字段就不會(huì)有password。深挖算法協(xié)商問(wèn)題這是一個(gè)更隱蔽的坑。有時(shí)客戶端和服務(wù)器支持的算法列表沒(méi)有交集導(dǎo)致密鑰交換失敗。雖然連接會(huì)早期斷開(kāi)但錯(cuò)誤信息可能很模糊。在Wireshark中對(duì)比仔細(xì)查看客戶端和服務(wù)器發(fā)出的SSH_MSG_KEXINIT數(shù)據(jù)包。展開(kāi)列表對(duì)比雙方的“密鑰交換算法”、“加密算法”等。例如舊的客戶端可能只支持diffie-hellman-group1-sha1而現(xiàn)代的服務(wù)器出于安全考慮已禁用此算法只支持group14或curve25519。這就導(dǎo)致了協(xié)商失敗。解決方案升級(jí)客戶端/服務(wù)器的OpenSSH版本或者在配置文件中顯式指定雙方都支持的算法。例如在客戶端的~/.ssh/config或服務(wù)器的/etc/ssh/sshd_config中可以使用KexAlgorithms,Ciphers,MACs等指令進(jìn)行配置。4.3 高級(jí)技巧解密SSH加密流量與跟蹤應(yīng)用數(shù)據(jù)默認(rèn)情況下Wireshark無(wú)法解密SSH流量因?yàn)闀?huì)話密鑰是在內(nèi)存中動(dòng)態(tài)生成的。但是對(duì)于調(diào)試和深度安全分析OpenSSH提供了一種將密鑰材料導(dǎo)出供Wireshark使用的機(jī)制。步驟設(shè)置環(huán)境變量在啟動(dòng)SSH客戶端時(shí)設(shè)置一個(gè)特殊的環(huán)境變量指示OpenSSH將會(huì)話密鑰寫入一個(gè)文件。SSH_DEBUG1 SSH_AUTH_SOCK ssh -o SetEnv SSH_DEBUG1 -o SetEnv SSH_DEBUG_WIRESHARK1 userhost更通用的方法是在客戶端機(jī)器的~/.ssh/config文件中為特定主機(jī)配置Host debug_host HostName your_server_ip User your_username SetEnv SSH_DEBUG_WIRESHARK1然后使用ssh debug_host連接。連接成功后在當(dāng)前目錄會(huì)生成一個(gè)名為ssh-XXXXXX.log的文件XXXXXX是隨機(jī)字符。在Wireshark中加載密鑰打開(kāi)Wireshark進(jìn)入編輯 - 首選項(xiàng) - 協(xié)議 - SSH。在“RSA keys list”或“Decryption keys”區(qū)域點(diǎn)擊“瀏覽”選擇剛才生成的.log文件。Wireshark會(huì)自動(dòng)識(shí)別其中的密鑰。重新加載抓包文件加載密鑰后關(guān)閉再重新打開(kāi)你的ssh_analysis.pcapng文件或者如果你正在實(shí)時(shí)抓包后續(xù)的SSH數(shù)據(jù)包就會(huì)被自動(dòng)解密。此時(shí)原本顯示為“Encrypted packet”的數(shù)據(jù)現(xiàn)在可以展開(kāi)看到內(nèi)部的SSH_MSG_CHANNEL_DATA等內(nèi)容甚至能看到你輸入的每一個(gè)命令和服務(wù)器返回的每一個(gè)字符。重要警告此方法導(dǎo)出的密鑰文件是高度敏感的它允許任何人解密此次會(huì)話的所有通信。務(wù)必僅在絕對(duì)安全的調(diào)試環(huán)境中使用并在調(diào)試結(jié)束后立即徹底刪除該密鑰文件。通過(guò)這個(gè)技巧你就能真正“看到”加密隧道內(nèi)的所有活動(dòng)對(duì)于理解SSH通道、端口轉(zhuǎn)發(fā)、SFTP等高級(jí)功能的數(shù)據(jù)流非常有幫助。當(dāng)然這也從另一個(gè)角度證明了SSH協(xié)議的安全性——在不知道這個(gè)特定會(huì)話的密鑰文件的情況下即使截獲了所有流量也無(wú)法解密其內(nèi)容。