如何安全地與團隊共享 SSH 金鑰和憑證

「SSH 金鑰傳我 Slack。」開發團隊經常聽到這句話。伺服器存取緊急，新成員需要設定環境，部署迫在眉睫卻缺少金鑰。

但這句簡單的話可能引發嚴重的安全事故。

SSH 金鑰共享為什麼特別危險

SSH 金鑰不同於一般密碼。它授予伺服器的完整存取權限。

比較項目	密碼	SSH 金鑰
權限範圍	特定帳戶	整台伺服器
外洩影響	該帳戶	伺服器上所有資料
更換難度	即時更改	重新產生 + 更新所有伺服器
雙因素驗證	支援	金鑰本身就是驗證

SSH 金鑰外洩意味著伺服器上的所有檔案、資料庫、程式碼都可被存取。

團隊需要共享 SSH 金鑰的情境

• 共享伺服器存取：團隊都需要存取的 Staging/正式伺服器
• 部署金鑰：CI/CD 流水線使用的金鑰
• SSL 憑證：負責人異動時的憑證更新
• API Secret：第三方服務整合的認證資訊
• 資料庫憑證：緊急故障回應

危險的共享方式

1. Slack/LINE 私訊

聊天紀錄永久儲存在伺服器上。任何人搜尋「ssh」或「key」就能找到之前共享的金鑰。

2. 郵件

永久保存在郵件伺服器上，一次轉寄就失控。

3. 共享雲端硬碟/Notion

細粒度權限控制困難，同步後本機殘留副本。

4. 提交到 Git 儲存庫

最危險。Git 歷史中永久保留，即使刪除檔案也可從歷史中復原。

安全的共享方式

方式 1：LOCK.PUB 加密備忘錄（一次性傳遞最佳選擇）

1. 在 LOCK.PUB 建立加密備忘錄
2. 貼上 SSH 金鑰或憑證內容
3. 設定強密碼
4. 將到期時間設為最短（1-4 小時）
5. 連結發 Slack，密碼電話告知
6. 接收者本機儲存金鑰後，連結到期

優勢：

• 金鑰不以明文儲存在任何持久伺服器上
• 到期後不可存取
• 聊天紀錄中不殘留金鑰原文

方式 2：金鑰管理器（大團隊適用）

HashiCorp Vault、AWS Secrets Manager、Google Secret Manager 等專業工具。

方式 3：SSH 憑證頒發機構（長期方案）

營運 SSH CA，為每個使用者簽發獨立憑證，從根本上消除金鑰共享需求。

方式 4：個人金鑰（最推薦）

原則：共享金鑰 < 個人金鑰
共享金鑰外洩 → 影響整個團隊
個人金鑰外洩 → 只影響該使用者

必須共享時的檢查清單

傳遞前

• 金鑰權限範圍是否已設為最小？
• 唯讀金鑰是否足夠？
• 能否設定 IP 限制？

傳遞時

• 金鑰和密碼是否透過不同管道傳送？
• 到期時間是否盡可能短？

傳遞後

• 確認接收者已安全儲存金鑰
• 確認共享連結/備忘錄已到期
• 監控金鑰使用日誌

金鑰輪換計畫

金鑰類型	建議輪換週期
正式伺服器金鑰	90 天
部署金鑰	90 天
SSL 憑證	每次續期
API Secret	90 天
開發/Staging 金鑰	180 天

DevOps 團隊安全檢查清單

• 所有伺服器是否使用個人 SSH 金鑰？
• 共享金鑰是否已設定 IP 限制？
• 離職員工的金鑰是否立即失效？
• 是否建立了金鑰輪換計畫？
• SSH 金鑰是否從未提交到 Git 儲存庫？
• 聊天紀錄中是否有明文金鑰殘留？
• 敏感資訊傳遞是否使用帶到期的管道？

總結

SSH 金鑰和憑證是伺服器安全的命脈。透過 Slack 私訊或郵件傳送就像把家鑰匙貼在公佈欄上。盡可能簽發個人金鑰，必須共享時使用最短到期時間的加密備忘錄。

立即建立加密備忘錄，安全傳遞 SSH 金鑰。

建立加密備忘錄