資安指南

不要把 root 金鑰交給可能被入侵的環境：SSH 金鑰的最小權限

你是否從 GPU 雲的 pod、CI runner 這類『臨時且可能被入侵的環境』向生產伺服器登記了 SSH 金鑰？一旦那把金鑰外洩，別人就能以 root 權限進入你的生產環境。本站從維運視角講清楚把金鑰做成最小權限的思路，以及用非 root 使用者＋command 限制金鑰『把能做的操作收窄到一個』的做法。

發布於 2026-06-11 更新於 2026-06-11 閱讀時間 2 分鐘

適用對象：從 GPU 雲的 pod、CI runner、一次性 VM 這類臨時環境透過 SSH 連到生產伺服器的人。這裡不講攻擊手法，只講把金鑰做成最小權限、縮小爆炸半徑這一件事。金鑰分離這塊地基，也請參考安全底線清單。

本站的視角：把臨時環境當作『不可信任的前提』來對待

用完即棄的運算環境，加固往往被往後拖，是可能被入侵的地方。在那裡放上通往生產的 root 金鑰，就像把家門的備用鑰匙扔在馬路上。本站採用按主機使用不同金鑰、收窄用途、不再需要的金鑰立刻摘除的維運方式（→ 分開金鑰把爆炸半徑降到最小）。把金鑰當作「漏了就全部打開的最重要資產」、而不是「方便的通行證」來對待，到頭來才是最安全的。

✗ 臨時環境放 root 金鑰

臨時環境被入侵 → 用那把金鑰以 root 進入生產 → 檔案、機密、其他服務全部都能搆到。

○ command 限制的非 root 金鑰

同一把金鑰即使外洩，能做的也只有指定的那一條命令。shell 和轉送都不行＝損害封閉在一個操作裡。

從一開始就把金鑰的『可達範圍』設計得小一些。外洩時的損害會大不相同。

為什麼臨時環境的 root 金鑰危險

臨時環境常因「反正馬上就刪」而省掉加固，在攻擊者眼裡是個容易下手的跳板。一旦那裡有生產的 root 金鑰，損害就會瞬間被放到最大。

root→全部

金鑰外洩生產被整個奪走

用完即棄

臨時環境加固被往後拖

重複使用

一把外洩暴露全部主機

最小權限

把操作收窄到一個損害也只有一個

舉個例子，為了從臨時立起來做運算的 pod 向生產作業，你把金鑰登記進 root 的 authorized_keys。方便是方便，但那個 pod 一旦被入侵，攻擊者就能用那把金鑰以 root 權限進入生產。實際上，無論入口是 RCE 還是金鑰外洩，最終「被盜的金鑰把生產抽走」的構圖都是一樣的（相關：RCE 導致金鑰被盜、被惡意扣費的故事）。

把金鑰做成最小權限的 3 個步驟

別再「圖方便就交出全部權限」，改成「把能做的事收窄到最小」。

摘掉臨時環境的 root 金鑰

不再使用的金鑰，就從生產的 ~/.ssh/authorized_keys 裡刪掉。處於閒置狀態刪掉也沒有影響。先把『放著不管』消除掉。

再次需要也不要回到 root

為生產作業重新登記時，不要用 root，而是新建一個專用的非 root 使用者，把金鑰登記給這個使用者。萬一外洩，可達範圍也僅限於這個使用者的權限。

改用『把能做的操作收窄到一個的金鑰』

在 authorized_keys 的金鑰行上加 command="..." 和 restrict。即使能用這把金鑰登入，也只能執行指定的那一條命令，連接埠轉送和 shell 也能禁止。即使外洩，也能把損害封閉在那一個操作裡。

# 在非root使用者的 authorized_keys 裡登記「把能做的操作收窄到一個的金鑰」的範例
# 用這把金鑰登入後，除指定命令外無法執行，轉送、PTY 也被停用
command="/usr/local/bin/deploy-pull",restrict ssh-ed25519 AAAA...rest-of-public-key deploy@ci

restrict 會把轉送、agent 轉送、PTY、X11 等一併停用，command="..." 則把可執行的處理固定為一個。只允許拉取部署、只允許某個指令稿——像這樣按用途分別做出收窄到單一目的的金鑰，是基本做法。

常見的（危險）結構

從臨時 pod / CI 把金鑰登記到生產的 root
用完的金鑰不刪、放著不管
一把金鑰在多台主機上重複使用
到處散發能拿到全權 shell 的金鑰

最小權限的結構

連到生產只用非 root 使用者
金鑰用command=「...」 restrict限定為一個操作
按主機／用途分開金鑰
不再需要的金鑰立刻從 authorized_keys 刪除

把『重複使用金鑰＝最重要資產』來對待

一旦把金鑰當成『方便的通行證』，就會不知不覺重複使用、忘記刪除。反過來想，把它當作漏一把就全部打開的最重要資產來對待。按主機、按用途分開，臨時環境裡不放生產的金鑰，放了就在用完後必定刪掉。僅此就能斬斷「一把外洩波及全局」這種最壞的連鎖。

本站是怎麼做的

本站按伺服器使用專用金鑰，不重複使用金鑰。部署把接收方設為非 root 的專用使用者，生產採用「不主動外出拉取，只負責接收」這種單向結構（→ 生產只負責接收）。不會從臨時運算環境向生產留下長期常駐的金鑰，只在需要時以最小權限連線。理由正如本文所述，就是為了在一處被入侵不會波及全局，預先把金鑰的可達範圍設計得小一些。

接下來讀

FAQ

Q為什麼把 root 金鑰放進臨時環境很危險？

GPU 雲的 pod、CI runner 這類臨時環境，因為用完即棄，加固往往被往後拖，所以可能被入侵。在那裡放上通往生產伺服器的 root 金鑰，那個環境一旦被入侵，連同金鑰一起，生產的 root 權限就會被奪走。原則是把臨時環境當作『不可信任的前提』來對待，不在其中放置通往生產的 root 金鑰。

Q如果還是想從臨時環境連到生產呢？

不要回到 root，而是新建一個專用的非 root 使用者，給這個使用者登記一把『把能做的操作限定為一個的金鑰』。在 authorized_keys 裡加上 command=「...」和 restrict，那麼即使能用這把金鑰登入，也只能執行指定的那一條命令。即使外洩，也能把損害封閉在那一個操作裡。

Q金鑰管理裡最重要的原則是什麼？

把『重複使用金鑰＝最重要資產』牢記於心，不要搭出漏一把就全被抽走的結構。按主機、按用途分開使用金鑰，不再需要的金鑰就從 authorized_keys 裡刪掉。這樣就能防止一把的外洩波及全局。