應對“刪庫跑路”的一種解決思路
開發人員經常需要訪問某些服務器，做一些檢查應用程序日志之類的工作。
一般來說，訪問過程是使用公私鑰加密來控制的，每位開發人員都會生成自己的公私鑰對。并且，每個開發人員的公鑰都會添加到他們有權訪問的每臺服務器上的 authorized_keys 文件中。
1. 痛苦的手動更改
到目前為止，這還沒什么問題。但是，當一名開發人員離職時又會發生什么事情呢？
在這種情況下，應該從所有服務器上刪除這位開發人員的公鑰。根據他們有權訪問的服務器數量，這可能會涉及很多工作。
更糟糕的是，如果這個環節都是手動操作的，那么操作員很有可能會忘了刪除某些服務器上的公鑰。也就是說，離職員工的訪問權限仍然保持啟用狀態。
2. 替代解決方案
有一些商業和開源解決方案可以幫助我們解決這一問題。這里的基本思想是，你在這類服務上添加并維護一個密鑰和訪問權限列表，需要刪除某個密鑰時，該密鑰將從所有服務器中刪除。
這聽起來不錯，但這種方案有一個很大的缺陷：它是潛在的單一故障源。如果某人獲取了對該服務的訪問權限，那就意味著他可以訪問你的所有服務器。而且，如果你無法訪問這個服務，在最壞的情況下，甚至會無法訪問所有服務器。
解決方案：簽名密鑰
當我遇到了這個問題時，我去 HackerNews 上問了問其他人是如何解決它的。
https://news.ycombinator.com/item?id=24157180
社區提供了一些很棒的建議和見解，而這個問題的最佳解決方案似乎是對密鑰進行簽名，本文會詳細給大家介紹一下。
基本思想
這個方法的基本思想是：你還是要為每位開發人員生成一個公鑰 - 私鑰對。但是，不要把公鑰上載到服務器上。
而是使用之前生成的，所謂的證書頒發機構（CA）密鑰對公共密鑰進行簽名。這個簽名就是生成了第三個證書文件，你將它還給開發人員，然后讓他們放在.ssh/文件夾中，和私鑰、公鑰放在一起。
在服務器上，你只需告訴服務器你的 CA 的公鑰，服務器就可以檢測用戶是否具有正確簽名的證書，并且僅允許擁有這種簽名證書的開發人員訪問自己。
優點
簽署證書時，可以定義這次簽署有效的時間。因此，如果你簽署的有效期為 3 個月，隨后開發人員離開了公司，那么 3 個月后，他們肯定將無法訪問任何服務器。
現在你會說：好吧，但我不想每 3 個月就對每個人的密鑰簽一次名，這個抱怨很合理。
一種辦法是讓這個流程自動化，例如，你可以構建服務，讓用戶在使用公司的電子郵件和密碼授權時可以自動獲得簽名證書，但這不在本文的討論范圍之內。
另一種簡單的替代方法是，你可以頒發有效期更長的證書。然后，如果有人離開公司，就可以撤消這個證書，也就是使其失效。你可以在服務器上放置一個無效證書列表，它們將不再接受用戶訪問。例如，可以通過 AWS S3 或其他存儲來存放這個列表，并在每臺服務器上定期創建一個 cronjob 來完成這一操作。
該怎么做？
了解了原理后，實際上做起來非常簡單。
首先，你要生成一個證書頒發機構的公鑰 - 私鑰對，你應該把這個私鑰放在非常安全的地方：
- umask 77 # you want it to be private
- mkdir ~/my-ca && cd ~/my-ca
- ssh-keygen -C CA -f ca -b 4096 # be sure to use a passphrase and store it securely
然后在你的服務器上，設置為允許由你的 CA 簽名的所有用戶訪問該服務器：
將 CA 的公鑰上傳到服務器上，例如放在/etc/ssh/ca.pub
在/etc/ssh/sshd_config中添加一行，指示服務器允許訪問由該證書簽名的用戶
- TrustedUserCAKeys /etc/ssh/ca.pub # Trust all with a certificate signed by ca.pub
為了使更改生效，你應該重新加載 ssh 服務：sudo service ssh reload。現在，如果一位開發人員生成了他的公鑰 - 私鑰對（例如ssh-keygen -t ecdsa -b 521），他們只需向你發送他們的公鑰（請注意，你永遠不需要發送任何私鑰！）。然后，你只需簽署他們的公鑰就能生成他們的證書：
- # Inside your ~/my-ca folder, sign their public key (here: id_ecdsa.pub)
- ssh-keygen -s ca -I USER_ID -V +12w -z 1 id_ecdsa.pub
各個部分的簡要說明：
- -s ca：你要使用 CA 進行簽名
- -I USER_ID：你的用戶 ID/ 用戶名
- -V +12w：證書過期前的有效時間，這里有效期為 12 周
- -z 1：此證書的序列號，以后可用它來讓這個證書無效，序列號應唯一
- id_ecdsa.pub：你要簽名的開發人員的公鑰
它將生成證書id_ecdsa-cert.pub，你可以將其發送給開發人員，然后將其放在〜/.ssh文件夾中的公鑰 / 私鑰對旁邊。
改進一下
聽起來不錯，但是你還可以做得更好！
你的組織里可能有很多擁有不同經驗水平、身處不同團隊、承擔不同職責的開發人員，并不是每個人都會訪問相同的服務器。
這樣的話，讓我們在簽名流程中添加角色吧。
這樣，你可以在服務器上設置允許哪些角色訪問服務器，并且在簽名過程中可以指定要簽名的開發人員的角色。
然后，這位開發人員就能訪問與其角色匹配的所有服務器。
當你添加新的開發人員時，只需生成一個證書即可讓他們獲得授權，訪問所有相關服務器，而無需在這些服務器上添加任何內容。
大致上是這樣的：
帶有角色的 ssh 證書簽名
下面是在服務器上配置角色的方式：
首先，創建用于配置訪問權限的文件夾：sudo mkdir /etc/ssh/auth_principals。在該文件夾中，你可以用允許登錄服務器的用戶名創建文件。例如，要對某些角色授予 root 訪問權限，請添加文件/etc/ssh/auth_principals/root。
在/etc/ssh/auth_principals/root內部，你只需列出所有可以用 root 身份登錄的角色，每行一個角色：
- admin
- senior-developer
最后，再在/etc/ssh/sshd_config中添加一行，在服務器上配置為使用角色：
- AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
為了使更改生效，你應該重新加載 ssh 服務：sudo service ssh reload。
下面是使用角色簽署密鑰的方式（它們已添加到證書中）：
- ssh-keygen -s ca -I USER_ID -n ROLE1,ROLE2 -V +12w -z 2 id_ecdsa.pub
這里和之前是一樣的，但帶有-n ROLE1,ROLE2標志。重要提示：不同角色的逗號之間不能有空格！現在，這位開發人員可以登錄 auth_principals 文件中有ROLE1或ROLE2的任何服務器，以獲取他們嘗試登錄時使用的用戶名。
注銷密鑰
最后，如果要使證書無效，可以通過用戶名或證書的序列號（-z標志）來實現。建議你在 Excel 電子表格中列出生成的證書列表，或者根據你的具體情況來建立數據庫。
- ssh-keygen -k -f revoked-keys -u -s ca list-to-revoke
當你已經有一個revoked-keys列表并想要更新它時（-u標志）就這樣做。對于初始生成，請拿掉更新標志。list-to-revoke需要包含用戶名（id）或序列號（生成期間為-z標志），如下所示：
- serial: 1
- id: test.user
這將撤消對序列號為 1 的證書以及 ID 為test.user的所有證書的訪問權限。
為了讓服務器知曉已注銷的密鑰，你需要將生成的 / 更新的revoked keys文件添加到/etc/ssh/revoked-keys，并在/etc/ssh/sshd_config中再次配置：
警告：確保revoked-keys文件可訪問且可讀，否則你可能無法訪問服務器
RevokedKeys /etc/ssh/revoked-keys
3. 小結：ssh 密鑰管理的好方法
我認為這種解決方案是最好用的。你可以選擇通過 ssh 基于角色管理對服務器的訪問權限。你只需配置一次服務器（允許哪些角色訪問服務器）即可。對于新加入的開發人員，你只需要生成一個簽名證書，他們就能立即訪問與他們的角色 / 經驗相匹配的所有相關機器。當他們離開公司時，你也可以通過一種簡單的方式撤銷他們的訪問權限。
即使發生不幸事故，并且開發人員在未取消訪問權限的情況下離開，他們的證書也會在一段時間后過期，因此他們也將自動失去訪問權限。
對小型團隊來說，你可以手動執行這些步驟，因為這些工作做起來非常快；然后隨著你的成長，可以使用基于公司身份驗證詳細信息的登錄服務來自動進行證書簽名。
