六台主機共用一把沒上鎖的鑰匙，
而通往它們的門其實一直開著

設計的意圖是對的，執行的信任是裸的

這個叢集的維運規則一句話講得完：所有人先登入跳板機，再從跳板機進其他主機。一台跳板機當唯一入口，下游約有六台應用與服務主機，作業系統都是 Ubuntu 16.04——一個 2021 年起就停止一般支援的版本。單一入口是個好主意，它把攻擊面收斂到一台、也讓稽核有個集中點。問題不在這個方向，在它底下那條沒有上鎖的信任鏈。

跳板機上的 root 持有一把 4096-bit 的 RSA 私鑰，而這把私鑰沒有 passphrase。沒有 passphrase 的意思是：任何能讀到這個檔案的人，都能直接拿它去登入，不需要再知道任何密語。這把私鑰的對應公鑰，被放進了下游每一台主機的 /root/.ssh/authorized_keys。於是「持有跳板機上那個檔案」就等於「擁有全叢集的 root」——中間沒有第二道關卡。

先把這篇會提到的兩把鑰匙擺出來。它們屬於兩條不同的信任鏈：一條是跳板機 root 對下游 root 的常設信任，另一條是進各台 ubuntu 帳號、而且曾經外洩過的共用維運私鑰。

兩把鑰匙的共同點，是它們都把「拿到一個檔案」直接等同於「拿到一批主機的身分」，中間沒有任何可以單獨撤銷、可以對應到個人、會自己過期的東西。

一個單字，就能開全叢集的 root

把這條信任鏈走一遍，最驚人的地方是它有多安靜：在跳板機上打一個單字 ssh 應用機，對方的 root shell 就開了，不問密碼。短名字來自 /etc/hosts（名字對應到內網 IP），而 ssh 不帶使用者時會沿用當下的身分——在 root 底下，就是以 root 去連 root。三件平凡的小事疊在一起，湊成了一條免密碼的全叢集通道。

到這裡，其實已經足夠理解這個設計的問題在哪。如果你關心的是制度上該怎麼改，可以直接往「該改的四件事」繼續閱讀。如果你想知道這條信任鏈具體長什麼樣、我們是怎麼從磁碟上確認它的，下面開始進入技術拆解。

接下來這一段會稍微技術一些。你不需要先懂 SSH 的細節，只要先記住一個結論：這把能開全叢集 root 的私鑰，既沒有上鎖，也沒有人需要先過第二關才能用它。

# 讀出私鑰指紋。不需要輸入密語就讀得到，代表這把私鑰沒有加密
ssh-keygen -lf 跳板機root私鑰
# 4096 SHA256:xxxxxxxx...（RSA）   ← 全程沒有要求 passphrase

  維運人員 ──ssh──▶ 跳板機（root，持有無 passphrase 的 4096-bit 私鑰）
                        │  ssh 短名（不帶使用者，沿用 root 身分；短名來自 /etc/hosts）
                        ▼
   ┌─────────┬─────────┬─────────┬─────────┐
  應用機     服務機     排程機     快取機   …（約 6 台）
   每台 /root/.ssh/authorized_keys 都放了那把的對應公鑰
   → 不問密碼，直接開 root shell

# 部署腳本實際長這樣（示意）：帶跳板機 root 私鑰、關掉主機金鑰檢查，再 rsync
ssh -i 跳板機root私鑰 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@內網IP
# 某台主機的登入紀錄裡，約 101 次來自跳板機內網 IP——這條路確實天天在走

這條通道本身是維運的便利，不是漏洞；真正讓它變成風險的，是下一節那件被當成理所當然的事。

「只能從跳板機進」只是慣例，網路沒有強制

整個設計的前提是「下游主機只能從跳板機進」。但這句話在這裡只是一條口頭約定，不是一道牆。從一個外部網路對那約六台主機的 22 port 逐一做 TCP 連線，每一台都連得上。也就是說，跳板機是不是唯一入口，取決於大家願不願意走它，而不是取決於網路放不放行。

這就是整篇最該翻過來看的一件事：這不是「跳板機設計得不好」的故事，是「跳板機設計得很好、但沒有人把它變成強制」的故事。收斂攻擊面的意圖，寫在一份約定裡；放行所有來源的事實，寫在防火牆規則裡。兩者不一致的時候，攻擊者讀的是後面那一份。

能連得上 22，不代表能登入——還要有鑰匙。偏偏鑰匙這一關，也沒有擋住。

三十天前，有人沒走跳板機就進來了

三十天前的登入紀錄裡，有一筆不該存在的連線：一次外來登入，來源是某個家用寬頻的動態 IP，用的是那把曾經外洩的共用維運私鑰，目標是其中一台主機的 ubuntu 帳號。它沒有先經過跳板機——因為網路沒有逼它經過，而鑰匙它手上有。

這一筆把前兩節的兩個弱點接成了一條完整的路：port 對外開著（所以連得上），私鑰曾以明文躺進某個對外服務的環境變數（所以鑰匙在外面）。至於按下這個連線的是不是自家人員，到現在仍在確認中，這一格我標成缺口。但要記住的重點不在那個人是誰，在於網路本來就允許了這條繞過跳板機的路；換成別人，結果一樣。

一次能繞過，比繞過一次嚴重。因為它證明的不是「有人進來了」，是「這條路一直開著」。

真正危險的是推論的那一步

到目前為止講的都有紀錄可查。接下來這一步沒有發生過，是推論，但它是這整個設計裡賭注最大的一格。

假設哪一天跳板機本身被攻破——它跑的也是 Ubuntu 16.04，一個停止支援的系統，被攻破不是什麼難以想像的事。攻破的人會在磁碟上撿到那把沒有 passphrase 的 root 私鑰，然後就結束了：他不需要再破任何密碼、不需要提權、不需要撞任何一台主機，一個單字 ssh 就能把全叢集的 root 一台一台開過去。這在攻防裡叫 lateral movement（橫向移動），而這套設計等於把橫向移動的成本預先降到了零。

這一格我寫成推論，是因為它確實還沒發生，我不把願望或恐懼當證據。但它也是最便宜就能拆掉的一格——只要那把 root 私鑰有 passphrase，或者乾脆不落地，這條推論就不成立。

該罵的是金鑰管理，不是方向

講到這裡要先替這個設計說幾句公道話，否則就變成為罵而罵。用公鑰認證取代密碼，是標準而且正確的做法，不該因為這篇就退回去用密碼。拿單一跳板機當入口，也是好設計——它收斂攻擊面、集中稽核點，值得保留。用 /etc/hosts 給主機取短名字，純粹是維運圖個方便，無傷大雅，跟安全沒有關係。

換句話說，這套系統每一個「方向」都對：對的認證方式、對的入口架構、對的操作習慣。出問題的全部集中在兩件事——金鑰沒有上鎖（沒有 passphrase、長期有效、共用），以及信任的範圍沒有邊界（root 對 root、網路不強制）。把這兩件分開看很重要：如果把「方向」也一起否定，最後只會換成一套更難用、而且未必更安全的東西。

該修的是鑰匙怎麼保管、信任到哪為止，不是要不要用鑰匙、要不要有跳板機。

這些主張的證據等級

這是設計弱點分析，不是一次已發生的入侵，所以更要把「哪些看得到、哪些只能推、哪些查不到」分清楚。

三條能證明、一條只能推、兩條查不到，湊起來剛好說明這類設計弱點的真相：它多半不在某一次攻擊的痕跡裡，而在你有沒有本事把自己的信任範圍畫清楚。

該改的四件事

修法由高到低有四件，而且愈靠前的愈該先做。

第一件，先處理那把萬能的 root 私鑰。最低限度是替它加上 passphrase，讓「持有檔案」不再等於「能直接用」；更好的做法是改走雲端原生的 Session Manager 這類連線方式，讓私鑰根本不落地在維運人員的機器上，連線也不需要對外開 22。這一件幾乎不花錢，卻能直接把上一節那條「跳板機失守即全叢集淪陷」的推論拆掉。

第二件，用個人帳號加 sudo 取代共用 root。每個人用自己的身分登入，要動 root 權限時才 sudo，這樣登入紀錄裡就會是具名的，而不是一片分不清誰是誰的「root from 跳板機」；有人離職，撤掉他那一把就好，不必全叢集換鑰匙。

第三件，把常設信任改成按需、短效。常年有效的授權是這整件事的燃料；改用 SSH CA 簽發有時效的憑證，讓每一次信任都有到期日，過期自動失效，比任何輪替流程都根本。第四件，也是補網路那道假牆：用 Security Group 把下游主機的 22 port 收斂成只允許跳板機來源，讓「只能從跳板機進」從一句約定變成一條規則。這一件擋不住已經在跳板機上的人，但能擋掉三十天前那種從家用寬頻直接連進來的路。

四件事排下來會發現，最該先做的那一件，剛好也是最便宜的那一件。

私鑰真的得存在某處時：三種 Secret 管理的差異

最好的私鑰是不存在的私鑰（Session Manager、短效 SSH CA 憑證）。但部署腳本、CI 這類機器身分，總有一段時間得拿到一把憑證；這時它該進 Secret 管理工具，而不是像本案那樣以明文 PEM 塞進環境變數。常見的三個選項差在這裡：

怎麼選：K8s Secret 不是保管庫，它的值預設只做 base64 編碼，etcd 靜態加密要叢集管理者另外設定，拿來放 SSH 私鑰前先確認這一格；主機都在 AWS 上，就用 Secrets Manager，KMS 加密、版本與輪替都內建，權限也能用 IAM 收到單一角色；多雲或團隊想在本機開發、CI、AI 編碼助理之間共用同一份來源，Infisical 這類工具比較順手。不管選哪個，判斷標準都一樣：誰能讀到這把鑰匙要查得到、要撤得掉，而且它不該出現在任何對外服務的環境變數裡。

這篇提到的項目要花多少錢

這不是一次已發生的帳單事件，而是設計弱點分析，所以這張表大方承認多列是缺口。真正值得看的不是金額，是「修這個洞要花多少」——答案接近零。

這張表沒有任何一列是可以證明的金額——不是因為沒有成本，是因為查核憑證過期、帳單根本拿不到，所以合計那一行是 0。但它也同時說清楚了一件事：下游幾台主機的帳單我們算不出來，可是「加 passphrase、開 Session Manager、簽 SSH CA 憑證」這幾件修補，花的錢接近零，貴的只有下定決心換掉共用 root 的那點力氣。

你可以學到什麼

站在攻擊者那一側看，這套設計的誘人之處不在於它有多脆，而在於它有多整齊。一台跳板機當唯一入口，等於替他標好了最高價值目標；一把沒有 passphrase 的 root 私鑰裸躺在那台機器上，等於告訴他「攻破這一台之後不會再有第二道門」；下游主機的 22 port 全開，等於他連跳板機都不急著攻，手上要是有任何一把能用的鑰匙，從家裡的寬頻就能先試一台。他要的不是你跑什麼服務，是「拿到一個檔案就能換到多少台主機的 root」這個匯率——而這套設計把匯率開得非常好。讓他無利可圖的方法，不是把鑰匙藏得更深，是讓每一把鑰匙都有鎖、有期限、對應得到人。

結尾：門與鑰匙

回到開頭那條規則：所有人先進跳板機，再進其他主機。它寫得很好，壞在兩個地方——通往其他主機的門其實一直開著，而那把能開全叢集的鑰匙沒有上鎖。三十天前那次從家用寬頻進來的登入，證明的不是誰做了什麼，是這扇門確實可以不經跳板機就推開。

要把這扇門關上，技術上一點都不難：加一個 passphrase、收一條防火牆規則、簽一張會過期的憑證。難的是承認一件事——方向對，不等於已經安全。至於那把萬能私鑰究竟還躺在幾個地方、那次登入的手是不是自家人，這兩個問題，要等我們把查核憑證重新辦好、把紀錄重新接上，才會有答案。

本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。