OpenSSH把證書藏了15年，運維發(fā)現(xiàn)后集體破防

2010年發(fā)布的OpenSSH 5.4版本里，藏著一套能解決90%服務(wù)器管理噩夢的機制。15年過去了，它依然躺在代碼庫里吃灰，而運維們還在手動復(fù)制粘貼公鑰到上百臺機器。

這不是技術(shù)落后，是認知斷層。

SSH證書（Certificate）的工作邏輯和TLS證書幾乎一模一樣：一個可信的證書頒發(fā)機構(gòu)（CA）簽發(fā)憑證，客戶端和服務(wù)器各自驗證這張憑證的真?zhèn)?。但OpenSSH的實現(xiàn)比TLS早了整整5年，卻幾乎沒人用。

問題出在路徑依賴。傳統(tǒng)SSH密鑰模型——每個用戶生成密鑰對，公鑰分發(fā)到每臺服務(wù)器的authorized_keys——在"一個人管三臺服務(wù)器"的場景下確實順手。一旦規(guī)模膨脹，這套模型就變成了運維的債務(wù)黑洞。

新員工入職？把他的公鑰塞進幾十臺機器的authorized_keys。有人離職？你根本記不清楚他的密鑰散落在哪些角落。第一次連新服務(wù)器？面對那個"是否信任此主機指紋"的提示，99%的人直接敲yes——這個習(xí)慣等于把中間人攻擊的邀請函貼在門上。

SSH證書把這一切壓縮成三條命令：生成CA密鑰對、簽發(fā)證書、配置信任錨。之后，用戶入職只需簽發(fā)一張證書，離職只需吊銷這張證書。主機身份由CA背書，不再需要人類用肉眼去"認"指紋。

證書模型 vs 傳統(tǒng)模型：一場不對稱的消耗戰(zhàn)

傳統(tǒng)模型的隱性成本被嚴(yán)重低估。Facebook在2016年開源的facebookincubator/certificates項目文檔里算過一筆賬：他們當(dāng)時管理著數(shù)萬臺服務(wù)器，傳統(tǒng)SSH密鑰的輪換周期是90天，每次輪換需要消耗約4000人時的工程時間。

證書模型的核心優(yōu)勢是"信任收斂"。傳統(tǒng)模型里，信任關(guān)系呈N×M的網(wǎng)狀擴散——N個用戶乘以M臺服務(wù)器。證書模型里，信任關(guān)系收斂到兩個錨點：用戶CA和主機CA。

這個設(shè)計直接復(fù)制了TLS證書的成熟經(jīng)驗。如果你理解瀏覽器怎么驗證HTTPS網(wǎng)站的身份，你已經(jīng)懂了SSH證書的80%。

但復(fù)制經(jīng)驗不等于復(fù)制代碼。OpenSSH的證書實現(xiàn)有幾處關(guān)鍵差異：

第一，SSH證書沒有證書鏈的概念。TLS世界里，根CA簽發(fā)中間CA，中間CA再簽發(fā)終端證書，形成可審計的信任鏈。SSH證書是扁平結(jié)構(gòu)，CA直接簽發(fā)給用戶或主機，簡化了實現(xiàn)，也限制了靈活性。

第二，SSH證書的有效期可以精確到秒。TLS證書通常以年為單位，SSH證書常見配置是按周或按月輪換。Facebook的生產(chǎn)環(huán)境用的是24小時有效期的用戶證書，配合自動化簽發(fā)系統(tǒng)，實現(xiàn)"憑證即服務(wù)"。

第三，SSH證書支持"主體"（Principal）的靈活定義。一張用戶證書可以聲明"這個用戶在所有web服務(wù)器上是www-data，在數(shù)據(jù)庫服務(wù)器上是dbadmin"，權(quán)限粒度由CA策略控制，而不是由每臺服務(wù)器的authorized_keys獨立配置。

這些差異說明，SSH證書不是TLS證書的拙劣模仿，而是針對服務(wù)器管理場景的定向優(yōu)化。

實操：兩條CA密鑰和三條命令

部署證書模型需要兩個獨立的CA：用戶CA（User CA）和主機CA（Host CA）。分離的目的是控制爆炸半徑——如果用戶CA私鑰泄露，攻擊者只能簽發(fā)虛假用戶身份；主機CA泄露，攻擊者只能偽造服務(wù)器身份。兩者同時泄露的概率，遠低于單一CA的災(zāi)難場景。

生成CA密鑰對的命令和生成普通SSH密鑰沒有區(qū)別，只是命名約定不同：

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

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

這兩條命令產(chǎn)出四個文件：user_ca和user_ca.pub，host_ca和host_ca.pub。帶.pub后綴的是公鑰，可以分發(fā)到任何需要驗證證書的地方。不帶后綴的是私鑰，需要按照根CA的安全標(biāo)準(zhǔn)保管——離線存儲、硬件安全模塊（HSM）、雙人控制，視你的威脅模型而定。

主機證書的簽發(fā)流程如下。假設(shè)你已經(jīng)有一臺運行中的服務(wù)器，它的主機密鑰通常位于/etc/ssh/ssh_host_ed25519_key.pub：

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

參數(shù)拆解：-s指定簽名用的CA私鑰；-I是證書標(biāo)識，僅用于日志審計；-h聲明這是主機證書（省略則默認為用戶證書，簽錯類型會導(dǎo)致驗證失敗）；-n列出證書綁定的主體，可以是主機名、IP地址或通配符；-V +52w設(shè)置有效期為52周。

執(zhí)行后生成ssh_host_ed25519_key-cert.pub，這就是主機證書。把它復(fù)制回服務(wù)器，然后在sshd_config里添加一行：

HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

重啟SSH服務(wù)，這臺服務(wù)器現(xiàn)在會向所有連接者出示證書，而不是裸公鑰。

客戶端側(cè)的配置更簡單。在~/.ssh/known_hosts或系統(tǒng)級的/etc/ssh/ssh_known_hosts里添加：

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

@cert-authority指令告訴SSH客戶端：對于匹配*.example.com的任何主機，只要它出示的證書能用后面這串公鑰驗證通過，就自動信任，不再提示指紋確認。

第一次配置完成后，新服務(wù)器上線不再需要人工確認指紋。新服務(wù)器只需要申請一張主機證書，客戶端側(cè)零變動。

用戶證書：入職一張證，離職一鍵廢

主機證書解決的是"服務(wù)器身份可信"問題，用戶證書解決的是"訪問權(quán)限可管理"問題。

為用戶簽發(fā)證書的流程類似，只是參數(shù)指向不同：

ssh-keygen -s user_ca \

-I "alice@example.com" \

-n "alice,www-data" \

-V +1d \

alice.pub

這里-n指定的是用戶名主體。Alice可以用這張證書登錄任何允許"alice"或"www-data"用戶的服務(wù)器。-V +1d把有效期壓到1天，強制每日續(xù)簽，降低憑證泄露后的窗口期風(fēng)險。

服務(wù)器側(cè)需要配置信任用戶CA。在sshd_config里添加：

TrustedUserCAKeys /etc/ssh/user_ca.pub

重啟后，這臺服務(wù)器接受任何由該CA簽發(fā)的用戶證書，authorized_keys文件可以徹底退役。

權(quán)限粒度控制通過證書的主體字段實現(xiàn)。你可以簽發(fā)一張證書讓Bob在所有web服務(wù)器上是www-data，在數(shù)據(jù)庫服務(wù)器上是readonly，在跳板機上保持bob。這種動態(tài)映射是傳統(tǒng)靜態(tài)authorized_keys無法實現(xiàn)的。

吊銷機制是證書模型的另一張底牌。OpenSSH支持兩種吊銷方式：證書序列號列表（Serial）和密鑰標(biāo)識列表（Key ID）。

序列號方式需要CA在簽發(fā)時分配唯一序列號（-z參數(shù)），然后維護一個吊銷列表文件：

RevokedKeys /etc/ssh/revoked_keys

文件格式每行一個十六進制序列號。用戶離職時，把他的證書序列號追加進這個文件，所有服務(wù)器即時生效。

密鑰標(biāo)識方式更粗暴：直接列出被吊銷的-I標(biāo)識符。適合小規(guī)模場景，大規(guī)模下查詢效率不如序列號。

吊銷的實時性取決于配置分發(fā)速度。如果你用Puppet、Ansible或類似工具管理revoked_keys文件，吊銷延遲等于你的配置管理周期。追求實時的話，需要把吊銷列表塞進集中式存儲，讓sshd動態(tài)加載。

為什么15年了還沒普及？

技術(shù)成熟度和采用率之間的鴻溝，從來不只是技術(shù)問題。

第一個障礙是工具鏈的缺失。TLS證書有Let's Encrypt、Certbot、ACME協(xié)議構(gòu)成的完整生態(tài)，申請、續(xù)期、部署可以全自動化。SSH證書沒有等價物，每個組織都要自己寫腳本、搭流程、造輪子。

Facebook開源的certificates項目是一個參考實現(xiàn)，但它綁定的是Facebook內(nèi)部基礎(chǔ)設(shè)施（如Kerberos認證），移植成本不低。Netflix的Bless項目更輕量，但2019年后停止維護。Square的ssh-ca、Lyft的ssh-cert-authority各有取舍，沒有形成社區(qū)共識。

第二個障礙是認知慣性。多數(shù)運維團隊把SSH密鑰管理當(dāng)成"已經(jīng)解決的問題"——盡管解決得很痛苦。痛苦被歸因為"規(guī)模大了就這樣"，而不是"模型選錯了"。

第三個障礙是安全審計的合規(guī)要求。很多企業(yè)的SOC 2、ISO 27001審計清單里，SSH密鑰管理條目還停留在"定期輪換""記錄訪問日志"層面，沒有強制要求證書模型。合規(guī)驅(qū)動力的缺位，讓技術(shù)升級變成純成本項。

但風(fēng)向正在變化。2023年，美國網(wǎng)絡(luò)安全與基礎(chǔ)設(shè)施安全局（CISA）發(fā)布的《聯(lián)邦機構(gòu)SSH安全指南》首次把證書模型列為"推薦實踐"。同年，歐盟NIS2指令的配套技術(shù)規(guī)范里，SSH證書被納入"安全通信"控制項的合規(guī)路徑之一。

云廠商的動作更快。AWS Systems Manager Session Manager支持通過SSH證書進行身份驗證，Google Cloud的OS Login服務(wù)底層就是證書模型，Azure的VM登錄擴展也在2022年添加了證書支持。

這些信號指向同一個判斷：證書模型正在從"最佳實踐"變成"基準(zhǔn)要求"。

對于還在傳統(tǒng)模型里掙扎的團隊，遷移路徑比想象中平緩。不需要一次性替換所有服務(wù)器，可以按業(yè)務(wù)單元逐步試點。用戶CA和主機CA可以獨立部署，先解決"服務(wù)器身份可信"問題，再推進"用戶權(quán)限可管理"。

關(guān)鍵決策是CA私鑰的保管策略。小型團隊可以用硬件安全密鑰（如YubiKey）存儲CA私鑰，簽名操作需要物理接觸。中型團隊考慮HashiCorp Vault、AWS KMS等托管HSM服務(wù)。大型團隊需要完整的密鑰 ceremony 流程，多人參與、分片存儲、審計日志缺一不可。

證書有效期是另一個需要權(quán)衡的參數(shù)。Facebook的24小時極端配置，背后是自動化簽發(fā)系統(tǒng)的支撐。手動簽發(fā)場景下，周級或月級有效期更現(xiàn)實。主機證書可以放寬到年級別，因為主機身份變更頻率遠低于人員流動。

主體字段的設(shè)計反映組織架構(gòu)。按項目團隊劃分？按職能角色劃分？按訪問級別劃分？證書模型的靈活性是把雙刃劍，前期規(guī)劃不足會導(dǎo)致后期證書泛濫、管理反噬。

一個務(wù)實的起點：先用主機證書解決"首次連接確認指紋"的痛點。這個場景的ROI最高——零用戶培訓(xùn)成本，立即消除中間人攻擊向量，為后續(xù)用戶證書推廣建立信任基礎(chǔ)。

當(dāng)你的團隊第一次SSH到新服務(wù)器而不再看到那個紅色的指紋警告時，那種體驗有點像從HTTP切換到HTTPS：之前覺得"反正沒出事"的習(xí)慣，在對比之下突然顯得荒唐。