公司，包括 GitHub。他們最近在他們的博客上發布了關于 SSH 私鑰暴露的公告：

[上周，GitHub] 發現 GitHub.com 的 RSA SSH 私鑰在公共 GitHub 存儲庫中被短暫暴露。

該公司向公眾保證，該密鑰僅用于保護“使用 RSA 通過 SSH 進行的 Git 操作”，這意味著沒有內部系統、客戶數據或安全 TLS 連接處于風險之中。他們通過檢測事件并更改密鑰立即做出反應：

“在世界標準時間 3 月 24 日 05:00 左右，出于謹慎考慮，我們更換了用于保護 GitHub.com 的 Git 操作的 RSA SSH 主機密鑰。”

因此，影響在時間和范圍上都受到限制：“此更改僅影響使用 RSA 通過 SSH 的 Git 操作。如果您使用 ECDSA 或 Ed25519 加密，那么您不會受到影響。 ”，據他們說。

這進一步證明，秘密蔓延不僅僅是由缺乏經驗的開發人員或新團隊推動的。在我們的State of Secrets Sprawl 2023 報告中，我們發現了超過 10,000,000 個被推送到公共 GitHub 存儲庫的新秘密。與去年的報告相比，我們檢測到的秘密數量增加了 67%，而 GitHub 本身的新帳戶只增加了 27%。

檢測到的硬編碼憑據的增加是由許多因素驅動的，但很明顯，參與事件的開發人員的資歷從新手到專家，以及來自各種成熟度級別的組織。從我們的報告中，我們發現十分之一的提交者在 2022 年泄露了一個秘密。如果您公開揭露了秘密，那么您肯定不是孤軍奮戰。GitHub 很好地提醒我們，無論我們的團隊有多大，我們都必須在安全實踐中保持警惕。

讓我們來看看這種情況下的風險是什么，GitHub 如何處理補救過程，以及一些避免公開私鑰的簡單步驟。

SSH 私鑰泄露的風險

GitHub 在他們的帖子后面說：“我們 [替換了我們的 RSA SSH 主機密鑰] 以保護我們的用戶免受任何攻擊者冒充 GitHub 或通過 SSH 竊聽他們的 Git 操作的機會。該密鑰不授予對 GitHub 基礎設施或客戶的訪問權限數據?！?/p>

雖然我們可以對最后一部分感到放心，但不會暴露任何客戶數據。還好沒有接管他們的基礎設施的已知風險，特別是考慮到有多少開發人員和如此多的互聯網每天都依賴它。

但“對手冒充 GitHub 或竊聽他們的 Git 操作”存在嚴重風險。這就是所謂的“中間人攻擊”，最終用戶無法區分合法的另一方和攻擊者。

由于有如此多的開發人員和服務依賴 GitHub SSH 通信來實現真正的安全，因此公司吊銷和替換他們的 SSH 密鑰非常有意義。在同一篇文章中，他們還發布了如果您受到影響需要做什么以及如何判斷您是否受到影響。如果在通過 SSH 連接到 GitHub 時收到警告，WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!則需要刪除舊密鑰或手動更新~/.ssh/known_hosts文件。

您的 GitHub Actions 也可能會受到影響。GitHub 輪換他們的 SSH 私鑰將意味著如果他們使用actions/checkoutssh-key 選項，工作流運行將失敗。這對于CircleCI 客戶來說可能很熟悉，他們因泄漏事件經歷過類似的意外工作流程中斷。

大量更換的反應和風險

正如預期的那樣，開發者社區對該事件有很多公眾反應。似乎沒有人對這種情況感到高興。但有些人在沒有添加太多評論的情況下幫助傳播信息。其他對話推測這可能是如何發生的，以及可能發揮作用的進一步潛在安全問題。在幾次談話中出現的一個問題是新的中間人攻擊的可能性。攻擊者知道密鑰將被許多開發人員使用命令替換，而無需手動驗證新指紋是否為預期值。壞人完全有可能在某些情況下插入自己的指紋。ssh-keygen -R github.com這是一個很好的提醒，我們應該擁抱零信任，從“信任，但驗證”轉變為“驗證，然后才信任”的立場。

事件補救的教訓

雖然不幸的是，GitHub 需要輪換此證書，影響了如此多的客戶，并發布了這樣的通知，但我們想強調他們用來響應事件的一些最佳實踐。

雖然我們不知道這個秘密暴露了多長時間，但我們可以假設它是最近才出現的。

迅速而謹慎地采取行動，不要驚慌失措，這對于秘密整治至關重要。鑒于他們發布的時間戳，我們可以假設這一事件導致相關團隊失眠，他們不得不權衡多種因素。他們似乎認為安全風險值得密鑰輪換，即使它可能會影響大量用戶。

我們也可以為他們非常迅速和公開的溝通鼓掌。雖然大多數人可能沒有訂閱 GitHub 博客，但他們將新聞推送到多個渠道盡可能公開。雖然社區中的一些人覺得在使用“我們沒有理由相信”或“非常謹慎”等術語時有點過多的“營銷旋轉”，但 GitHub 團隊在他們所有的溝通中一直直截了當安全事件。我們將采取一些溫和的措施，而不是沒有得到包括補救步驟的概述。

如何防止憑證泄露

沒有人是完美的，我們都會不時犯錯誤。期望人類總是完美地交付只會讓你失望，尤其是在處理像 Git 這樣概念上復雜的東西時。雖然我們都喜歡世界上最受歡迎的版本控制系統，但大多數開發人員會告訴您，做錯事太容易了，例如推送到錯誤的遠程存儲庫。

雖然我們不知道究竟是什么導致了這一特定事件，但我們想借此機會提醒您一些最佳做法。

永遠不要將憑據添加到版本控制

這一點看起來很明顯，但我們所有接觸代碼的人有時都會為此感到內疚。有時，尤其是在調試某些東西時，您只需要測試憑據是否有效。密碼、API 密鑰以及與之相關的證書都是如此。

您可能會直接在項目中添加一個新證書，完全有意將其移動到安全的地方或修改您的.gitignore文件，但是生活發生了，您會分心。一個git add -A和git commit以后，您的證書現在在您的 git 歷史記錄中。一個'git push'之后，它現在在共享倉庫中。

這就是 git hooks 和ggshield等工具真正派上用場的地方。設置預提交掛鉤非?？焖俸秃唵?。設置完成后，每次提交代碼的嘗試都將觸發掃描，如果在任何跟蹤文件中發現秘密，掃描將停止操作。在秘密成為您的 git 歷史的一部分之前捕獲秘密是補救這種情況的最安全和最便宜的地方。

仔細檢查遙控器是否正確

Git 的優勢之一是能夠輕松地將所有更改推送到您有權連接的任何遠程存儲庫。不幸的是，這很快就會變得混亂。假設您有兩個存儲庫，一個是公共的，一個是私有的，分別具有遠程名稱 proj-1-p和proj-1-pr。你只差一個字母就可能被推到錯誤的地方。意外發生。使這些起源名稱更明確是一個很好的主意。

許多開發人員處理的另一個因素是他們自己的 shell 別名。例如，通常將別名gpo作為經常鍵入的快捷方式git push origin。很容易進入自動模式并使用可能將錯誤分支發送到錯誤位置的快捷方式。如有疑問，請輸入。

經常輪換秘密

雖然此事件可能不需要輪換 SSH 密鑰，但您知道上次輪換它是什么時候嗎？是這個十年嗎？如果您不知道，那么現在是補救的好時機。任何有效憑證存在的時間越長，該憑證被發現和濫用的機會就越大。

我們發現，在秘密管理成熟度方面，更頻繁地輪換密鑰的團隊處于金字塔的頂端，即專家級別。在沒有緊急情況的情況下定期輪換證書將使您做好準備，以便在出現這些額外壓力時更好地應對。

保持警惕和安全

泄漏有時會發生在我們所有人身上，甚至發生在像 GitHub 這樣的大型平臺上。雖然可能有許多工作流程受到影響，并且許多開發人員需要更新他們的known_hosts文件，但由于 GitHub 對事件進行了明確的溝通，因此有明確的補救路徑，而且我們知道事件的總體范圍。

現在也是反思您自己的秘密管理和檢測策略的好時機。