科技 · 實用指南

SSH 顯示「too many authentication failures」？改伺服器前先數清已提交的金鑰

正確金鑰即使存在，也可能尚未輪到就被斷線。先證明實際主機、使用者、身分清單與提交順序，再做單金鑰測試，不要先清空代理或提高 MaxAuthTries。

作者 Watch at Ease News · 4 分鐘閱讀發布於 2026年10月16日凌晨3:09 UTC

「Too many authentication failures」代表單次連線的驗證嘗試額度已耗盡，不代表有人反覆輸錯密碼。OpenSSH 用戶端可能從設定檔與代理提交多把公鑰；每個遭拒嘗試都會消耗伺服器額度，所以伺服器可能在正確金鑰之前中斷。

保留失敗終端並查證實際路徑。不要先執行`ssh-add -D`、全域設定`IdentitiesOnly yes`、刪除金鑰檔或普遍提高`MaxAuthTries`。這些動作會抹去證據、影響其他主機，或在未證明原因時削弱伺服器保護。

1. 固定失敗目標並查看有效設定

使用發生失敗的同一終端、主機別名與使用者，記錄命令但不要複製秘密。若由 Git、IDE 或自動化包裝器啟動 SSH，先確認它真正傳入的主機與使用者。

若主機或使用者錯誤，先修正路由並重做診斷，不要靠刪除身分補償錯誤帳戶。

在失敗終端執行`ssh-add -l -E sha256`。它列出代理指紋，但不表示每把都會提交，也不包含用戶端直接載入的所有檔案；無法連絡代理時應如實記錄。

執行一次`ssh -vvv user@your-host`，找到每行「Offering public key」，僅依序記錄金鑰類型與 SHA256 指紋。分享前遮蔽位址、使用者與私有路徑。關鍵是預期指紋是否在斷線前出現。

若多把意外金鑰排在前面，這是選擇順序問題。若只提交正確金鑰仍遭拒，改查使用者、authorized_keys、憑證主體、代理簽章或伺服器政策。

用`ssh-keygen -lf /path/to/key.pub -E sha256`確認預期指紋，再執行`ssh -o IdentitiesOnly=yes -i /path/to/key user@your-host`。它只限制這次連線，不改變代理與其他金鑰。

若測試成功，伺服器、帳戶與金鑰能協同運作；原故障來自較廣用戶端環境的選擇或順序。為該別名保存窄範圍 Host 區塊，寫明 HostName、User、IdentityFile 與`IdentitiesOnly yes`，再用`ssh -G`及`ssh -vvv`驗證。

若測試失敗，保留詳細紀錄。單把正確金鑰後的 Permission denied 或代理簽章拒絕是其他分支；提高 MaxAuthTries 或清空代理都不能證明金鑰已授權且可用。

單一主機優先使用主機專屬區塊。除非已稽核所有目的地，不要讓 IdentityFile 落在錯誤範圍或把`IdentitiesOnly yes`設為全域。GitHub 與 GitLab 都記錄按主機選擇多金鑰的方式。

其他代理身分若仍供別的系統使用就保留。只有獨立確認已淘汰時才卸載；不要把刪除當成診斷捷徑。GUI 用戶端若忽略 OpenSSH 設定，應確認其自身代理與身分控制。

只在獨立伺服器政策審查中考慮 MaxAuthTries。此事件的完成條件是用戶端提交正確指紋並驗證成功，而不是取得更多嘗試。

HostName 或 User 錯誤 — 先修正目標，保持金鑰狀態不變。

斷線前有多個意外指紋 — 做單金鑰測試，再設定窄範圍 Host 區塊。

只提交正確指紋仍遭拒 — 轉入伺服器授權或簽章診斷。

單金鑰測試成功 — 保留其他身分並驗證修復後設定。

用戶端不是 OpenSSH 或忽略 ssh_config — 先識別其代理與選擇控制。