快捷導(dǎo)航

Jenkins服務(wù)器更新密鑰后任務(wù)構(gòu)建不了的排查實(shí)錄與解決方案

更新時間：2026年05月22日 09:15:13 作者：Linux運(yùn)維技術(shù)棧

在一次生產(chǎn)環(huán)境的 SSH 密鑰輪換中,我遇到了一個極其令人困惑的問題：在 Jenkins 服務(wù)器上手動執(zhí)行 ssh -i 命令測試新密鑰到目標(biāo)服務(wù)器,直接報(bào) Permission denied,本文記錄了完整的排查過程,希望能幫助遇到類似故障的運(yùn)維人員快速定位問題,需要的朋友可以參考下

前言：在一次生產(chǎn)環(huán)境的 SSH 密鑰輪換中，我遇到了一個極其令人困惑的問題：在 Jenkins 服務(wù)器上手動執(zhí)行 ssh -i 命令測試新密鑰到目標(biāo)服務(wù)器，直接報(bào) Permission denied；將同樣的命令放入 Jenkins 任務(wù)腳本中，同樣失敗。在排除了文件權(quán)限、換行符、known_hosts 等所有常見原因后，最終發(fā)現(xiàn)是 ssh-agent 緩存的老密鑰在“作祟”，而解決方法是在 ~/.ssh/config 中為堡壘機(jī)單獨(dú)配置 IdentitiesOnly yes。

本文記錄了完整的排查過程，希望能幫助遇到類似“幽靈”故障的運(yùn)維人員快速定位問題。

一、現(xiàn)象：手動測試失敗，Jenkins 任務(wù)也失敗

在 Jenkins 服務(wù)器上執(zhí)行以下命令手動測試新密鑰：

ssh -i ~/.ssh/id_ed25519_new -J user@bastion_ip:22222 target_ip "echo '連通'"

結(jié)果： 報(bào) Permission denied。

再將同樣的命令放入 Jenkins 任務(wù)腳本中：

scp -i ~/.ssh/id_ed25519_new -o 'ProxyJump user@bastion_ip:22222' ...

結(jié)果： Jenkins 控制臺同樣輸出 Permission denied。

手動與腳本表現(xiàn)一致——說明問題不在 Jenkins 任務(wù)執(zhí)行環(huán)境，而在基礎(chǔ)的 SSH 連接鏈路本身。

二、排查：繞過的彎路

檢查服務(wù)器端 authorized_keys：確認(rèn)新公鑰已正確添加，權(quán)限為 600，文件末尾有換行符。
重置 known_hosts：ssh-keygen -R bastion_ip，無效。
在腳本中增加參數(shù)：-o StrictHostKeyChecking=no，依然報(bào) Permission denied。
清空 ssh-agent 緩存：ssh-add -D，依然無效。

這些操作均無法解決問題，說明問題不在表面，而在 SSH 認(rèn)證的深層機(jī)制。

三、真相：SSH 的密鑰優(yōu)先級順序

經(jīng)過反復(fù)驗(yàn)證，發(fā)現(xiàn) SSH 在認(rèn)證時的密鑰優(yōu)先級是：

最高優(yōu)先級：ssh-agent 中緩存的密鑰。
中間優(yōu)先級：命令行 -i 參數(shù)指定的密鑰。
最低優(yōu)先級：~/.ssh/id_rsa 等默認(rèn)密鑰。

在 Jenkins 節(jié)點(diǎn)上，后臺進(jìn)程悄悄地啟動了 ssh-agent，并將舊的 id_rsa 密鑰加載了進(jìn)去。

當(dāng)我們在手動測試或 Jenkins 腳本中執(zhí)行 ssh -i ~/.ssh/id_ed25519_new ... 時，SSH 客戶端會優(yōu)先問 ssh-agent：“你有能用的鑰匙嗎？”

ssh-agent 回答：“有，我這里有 id_rsa。”

于是 SSH 嘗試用 舊密鑰 id_rsa 去連接堡壘機(jī)。此時，堡壘機(jī)上的老公鑰已被刪除，認(rèn)證失敗，連接被服務(wù)端直接切斷。切斷后，SSH 根本沒機(jī)會再去嘗試你 -i 指定的新密鑰。

這就是為什么手動測試和 Jenkins 任務(wù)都失敗的根本原因。

四、終極解決方案：配置~/.ssh/config

在 Jenkins 節(jié)點(diǎn)上，修改 ~/.ssh/config 文件，為堡壘機(jī)添加強(qiáng)制隔離配置：

Host bastion_ip
    IdentitiesOnly yes
    IdentityFile ~/.ssh/id_ed25519_new
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

核心參數(shù)解析：

bastion_ip：指構(gòu)建任務(wù)時的目標(biāo)服務(wù)器的ip，這里可以配制多個，用空格隔開，比如10.0.0.1 10.0.0.2 10.0.0.3。
IdentitiesOnly yes：強(qiáng)制 SSH 客戶端只使用 IdentityFile 指定的密鑰，完全忽略 ssh-agent 中緩存的所有密鑰。這是解決“-i 參數(shù)失效”的關(guān)鍵。
IdentityFile：指定要使用的新密鑰文件。
StrictHostKeyChecking no & UserKnownHostsFile /dev/null：跳過主機(jī)指紋校驗(yàn)，避免 SSH 在自動化環(huán)境中卡住。

五、驗(yàn)證與成果

添加配置后，再次執(zhí)行手動測試命令（不再需要 -i 參數(shù)）：

ssh -J user@bastion_ip:22222 target_ip "echo '連通'"

結(jié)果： 成功輸出 連通。

直接重跑 Jenkins 任務(wù)——構(gòu)建成功，密鑰輪換完成。

六、經(jīng)驗(yàn)總結(jié)：下次輪換密鑰該怎么做？

不要依賴腳本里的 -i 參數(shù)：在 Jenkins 這種有 ssh-agent 的環(huán)境里，單獨(dú)指定 -i 往往不可靠，因?yàn)?ssh-agent 的優(yōu)先級更高。
善用 ~/.ssh/config：為跳板機(jī)或目標(biāo)服務(wù)器單獨(dú)配置 IdentitiesOnly yes 和 IdentityFile，可以做到“一勞永逸”。
清理服務(wù)器端的舊公鑰：確保新公鑰是唯一可用的。
后續(xù)輪換：下次更新密鑰時，你只需要修改 ~/.ssh/config 里的 IdentityFile 路徑，所有 Jenkins 任務(wù)會自動切換到新密鑰，無需修改任何 Jenkins 腳本。