SSH 缺乏 Host 標頭機制

背景

在雲端服務成本日益增加的背景下，exe.dev 團隊面臨一個技術挑戰：如何在不為每個虛擬機（VM）分配獨立公網 IPv4 地址的前提下，讓使用者能透過一致的網域名稱直接進行 SSH 連線。由於 HTTP 協議擁有 Host 標頭可供反向代理識別目標，但 SSH 協議缺乏類似機制，開發團隊最終設計出一套結合「用戶公鑰」與「特定入口 IP」的二元組路由方案，實現了在共享 IP 環境下的 SSH 存取。

社群觀點

這項解決方案在 Hacker News 引發了關於開發者體驗（DX）與網路工程實務之間的熱烈討論。許多留言者首先質疑為何不採用更簡單的「非標準連接埠」或「IPv6」方案。支持者認為，exe.dev 的核心價值在於極致的易用性，讓 ssh domain.com 與瀏覽器訪問保持一致，能避免企業防火牆封鎖非 22 號連接埠的問題，並省去使用者手動配置 SSH Config 的麻煩。然而，反對者則指出，這種做法本質上是為了維持 IPv4 遺產而進行的過度工程，認為在 2025 年，推動 IPv6 或是針對 IPv4 額外收費才是更符合長遠發展的商業路徑。

技術層面的安全性與潛在限制是討論的另一個焦點。有評論者擔心，這種路由機制存在擴展性上限，因為單一用戶擁有的虛擬機數量不能超過服務商提供的入口 IP 總數，否則當同一個公鑰對應到同一個 IP 時，系統將無法判別目標。此外，由於 SSH 握手過程中，伺服器必須先出示主機金鑰（Host Key）才能接收用戶公鑰，這意味著所有透過該代理進入的虛擬機可能必須共享相同的主機金鑰，這在嚴格的安全審查下可能被視為一種中間人攻擊（MitM）的變體。雖然有觀點認為雲端服務商本就擁有硬體控制權，中間人風險在所難免，但這仍讓部分注重安全性的開發者感到疑慮。

此外，社群也貢獻了多種替代思路。有人建議利用 TLS SNI 進行重定向，或是採用 SSH 跳板機（Jump Host）配合 Shell 別名來達成類似效果。更有資深開發者分享了利用「敲門技術」（Port Knocking）動態產生 NAT 規則的黑科技做法。部分討論則延伸到 SSH 協議本身的設計缺陷，認為 SSH 缺乏像 HTTP 或 TLS 那樣的現代化封裝，導致公鑰在網路上容易被關聯出真實身份，缺乏隱私保護。整體而言，社群雖然認可 exe.dev 解決問題的創意，但對於這是否為「正確」的架構仍有分歧，多數人傾向於將其視為一種追求極致用戶體驗而妥協出的精巧設計。

延伸閱讀

在討論過程中，參與者提及了幾個與 SSH 代理及安全性相關的工具與研究。針對 SSH 路由與轉發，有網友推薦了 sshpiper 與 sshproxy 等開源專案，這些工具能協助在中間層處理 SSH 連線導向。在安全性研究方面，Cryptography Caffe 發表的一份關於網路上數百萬個 SSH 公鑰的調查報告也被引用，該研究探討了 SSH 金鑰因缺乏憑證封裝而導致的誤用與隱私洩漏風險。此外，關於 DNS 擴充功能的討論中，也提到了 SRV 紀錄 在 LDAP 與 Kubernetes 環境中的應用，作為一種比 Host 標頭更標準化的服務發現手段。