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