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

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

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

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

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

結果： 報 Permission denied。

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

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

結果： Jenkins 控制臺同樣輸出 Permission denied。

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

二、排查：繞過的彎路

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

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

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

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

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

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

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

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

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

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

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

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

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

核心參數(shù)解析：

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

五、驗證與成果

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

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

結果： 成功輸出 連通。

直接重跑 Jenkins 任務——構建成功，密鑰輪換完成。

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

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

希望這篇博客能幫你快速定位這類 Jenkins 密鑰更新后的連接失敗問題。如果你也遇到過類似的“幽靈”報錯，不妨試試在 ~/.ssh/config 里加上 IdentitiesOnly yes，或許能節(jié)省數(shù)小時的不必要排查。

以上就是Jenkins服務器更新密鑰后任務構建不了的排查實錄與解決方案的詳細內容，更多關于Jenkins更新密鑰后任務無法構建解決的資料請關注腳本之家其它相關文章！

最新評論