OpenSSH藏了15年的證書功能，運維發現后集體破防

全球超過900萬臺服務器每天在用SSH，但97%的運維團隊還在用2010年就該淘汰的鑰匙管理方式。

這不是夸張。當你第50次給新員工批量添加公鑰、第20次翻日志找離職員工的殘留權限、第N次對著"Are you sure you want to continue connecting?"發呆時——OpenSSH 5.4版本（2010年3月）就內置的證書體系，正在角落里吃灰。

本文用一次完整的技術考古，還原這套被嚴重低估的基礎設施。

01 鑰匙管理的三重崩潰

傳統SSH模型在"一個人三臺服務器"的場景下優雅簡潔。公鑰丟進authorized_keys，私鑰本地保管，連接時雙向驗證。

規模擴張后，這套模型開始系統性崩解。

第一重：分發災難。每來一名開發，運維需要把他的公鑰寫入N臺服務器的authorized_keys。N=50時是體力活，N=500時是自動化腳本，N=5000時沒人知道哪些服務器還存著三年前的舊鑰匙。

第二重：回收黑洞。員工離職時，HR發一封郵件給IT部門。但鑰匙散落在哪些機器上？生產環境、測試集群、那臺2019年部署的遺留數據庫？沒有中央登記冊，只能靠人腦和grep命令碰運氣。

第三重：信任幻覺。第一次連接新服務器時，SSH客戶端拋出一串十六進制指紋，問你"確定要繼續嗎？"。你確定嗎？你打電話給同事核對過嗎？還是像99%的人一樣直接敲了yes，把中間人攻擊的風險埋進known_hosts？

這三件事每天都在發生。不是邊緣案例，是核心痛點。

證書體系的設計者早就看穿了這一切。

02 證書如何重構信任鏈

理解SSH證書的最快方式：把它想象成TLS證書的精簡版。

你不是給每臺服務器分發1000把用戶公鑰，而是建立一個證書頒發機構（Certificate Authority，CA）——本質上就是一對特殊的SSH密鑰。CA用私鑰簽發證書，公鑰作為信任錨點預置在所有客戶端。

驗證流程被壓縮成一步：客戶端檢查服務器出示的證書是否由可信CA簽名。是，則放行；否，則拒絕。沒有指紋核對，沒有首次連接的信任建立，沒有authorized_keys的爆炸式增長。

實際操作中需要兩個CA，物理隔離。

用戶CA（User CA）負責簽發用戶證書，證明"持有此證書的人被允許登錄哪些服務器"。主機CA（Host CA）負責簽發主機證書，證明"這臺服務器的身份真實有效"。

分離的意圖很直白：如果用戶CA私鑰泄露，攻擊者只能偽造用戶身份，無法冒充服務器誘導中間人攻擊。反之亦然。爆炸半徑被鎖死在單一維度。

生成CA密鑰的命令平淡無奇，但后果重大：

# 用戶CA——這是你組織里最敏感的私鑰之一

ssh-keygen -t ed25519 -f user_ca -C "user-ca@yourorg"

# 主機CA——同樣級別保護

ssh-keygen -t ed25519 -f host_ca -C "host-ca@yourorg"

這兩行命令輸出的私鑰文件，應該進入硬件安全模塊（HSM）或至少離線存儲。它們的權限位、備份策略、訪問審計，需要對標根TLS CA的管控標準。

03 主機證書的部署實戰

假設你已經有一臺運行中的生產服務器，主機密鑰對早已生成。證書化的第一步：用主機CA的私鑰對現有公鑰簽名。

ssh-keygen -s host_ca \

-I "webserver-prod-01" \

-h \

-n "webserver-prod-01.example.com,10.0.1.50" \

-V +52w \

/etc/ssh/ssh_host_ed25519_key.pub

參數拆解：-s指定簽名私鑰，-I是證書標識（會出現在審計日志里），-h聲明這是主機證書而非用戶證書，-n列出證書適用的主機名和IP，-V設置有效期（這里是52周）。

輸出文件是ssh_host_ed25519_key-cert.pub，與原公鑰同名但多了-cert后綴。把它拷回服務器，在sshd_config里加一行：

HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

重啟sshd。這臺服務器現在向所有連接者出示密碼學簽名過的身份證明，而不是裸奔的公鑰指紋。

客戶端側的配置更簡潔。把主機CA的公鑰寫進known_hosts，但用特殊語法：

@cert-authority *.example.com ssh-ed25519 AAAA...your-host-ca-public-key...

@cert-authority指令告訴SSH：對于匹配*.example.com的任何主機，信任由其簽發的證書。首次連接時，客戶端驗證證書簽名而非詢問用戶，中間人攻擊的窗口被徹底關閉。

04 用戶證書：權限的精細化雕刻

主機證書解決了"服務器是誰"的問題，用戶證書解決"誰能進來、能做什么"。

生成用戶證書的過程與主機證書對稱，但多了權限控制的維度。

ssh-keygen -s user_ca \

-I "alice@example.com" \

-n "alice,webadmin,dbreadonly" \

-V +1w \

-z 1 \

alice.pub

關鍵在-n參數。這里列出的"alice,webadmin,dbreadonly"叫principals（主體標識），是SSH證書最核心的設計之一。

服務器端的sshd_config可以針對principals做細粒度授權：

Match Principals "webadmin"

AllowUsers alice bob carol

ForceCommand /usr/bin/audit-shell

或者更常見的：直接用principals映射到系統賬戶。

AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

文件/etc/ssh/auth_principals/root里寫一行"emergency-oncall"，持有對應證書的人就能以root身份登錄——不需要在服務器上預置他的公鑰，不需要知道他明天會不會離職。

證書有效期是另一道保險。上面例子里的-V +1w意味著證書一周后自動失效。短期證書+自動化簽發流水線，是現代零信任架構在SSH層的落地形態。

05 為什么15年過去還是小眾

技術方案在2010年就成熟了，生態停滯在文檔和工具鏈。

OpenSSH的證書實現是完整的，但周邊基礎設施幾乎空白。沒有Let's Encrypt式的免費CA，沒有主流云廠商的托管服務，沒有Terraform/Ansible的原生模塊（直到近年才改善）。

更深層的原因是心智模型沖突。TLS證書的普及得益于瀏覽器的強制推行——地址欄掛鎖不給就報警。SSH沒有UI層，沒有視覺反饋，證書的優勢（消除首次連接警告）對用戶不可見，只減輕運維負擔。

而運維團隊的遷移成本是真實的：現有authorized_keys的審計清理、CA密鑰的 ceremonies（生成儀式）、證書簽發流程的自動化、監控告警的重建。在"能用就別動"的基礎設施文化里，這優先級天然靠后。

但變化正在發生。

HashiCorp Vault、Teleport、Smallstep等工具把SSH證書納入零信任產品矩陣。GitHub在2021年宣布支持SSH證書簽名提交。AWS、GCP的托管服務開始原生集成主機證書。

技術債務的償還周期，往往以安全事件的頻率為節拍器。

當你的團隊下次面對"緊急撤銷某員工所有服務器權限"的工單時，是準備grep 500臺機器的authorized_keys，還是檢查CA吊銷列表后重新簽發一批證書？