SSH の「too many authentication failures」？サーバー変更前に提示キーを数える

1. 失敗した宛先と有効設定を固定する

失敗時と同じシェル、ホスト別名、ユーザー名を使います。秘密を含めずにコマンドを記録し、Git、IDE、自動化が SSH を起動した場合は実際に渡した宛先を確認します。

`ssh -G your-host | grep -Ei "^(hostname|user|identityfile|identityagent|identitiesonly|preferredauthentications) "`を実行します。まず HostName と User を照合し、すべての IdentityFile を確認します。Include や一致ブロックで加算されることがあります。

宛先かユーザーが誤っていれば先に修正して再診断します。誤ったアカウントを鍵削除で補わないでください。

2. 利用可能な ID と実際の提示順を比較する

失敗したシェルで`ssh-add -l -E sha256`を実行します。接続中のエージェントの指紋一覧であり、すべてが提示される保証でも、直接読み込む鍵ファイルの一覧でもありません。

`ssh -vvv user@your-host`を 1 回実行し、「Offering public key」ごとに鍵種別と SHA256 指紋だけを順番に記録します。共有前にアドレス、ユーザー、私有パスを伏せ、目的の指紋が切断前に現れるか確認します。

意図しない鍵が先に多数出れば選択順の問題です。目的の 1 鍵だけが提示されても拒否されるなら、ユーザー、authorized_keys、証明書プリンシパル、署名、サーバーポリシーへ移ります。

3. 何も削除せず 1 鍵テストを行う

`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`で再確認します。

失敗したら詳細ログを保存します。1 鍵後の Permission denied やエージェント署名拒否は別分岐です。MaxAuthTries 増加やエージェント消去では認可と使用可能性を証明できません。

4. 最小の恒久修正だけを行う

1 ホストにはホスト専用ブロックを使います。全宛先を監査していないなら IdentityFile を広い範囲に置いたり`IdentitiesOnly yes`を全体化しないでください。GitHub と GitLab もホスト単位の鍵選択を案内しています。

他システムで使うエージェント ID は残します。廃止済みと別途確認した鍵だけを外し、診断のために削除しません。GUI クライアントが OpenSSH 設定を無視するなら、その製品独自のエージェントと選択設定を確認します。

MaxAuthTries は別のサーバーポリシー審査でのみ検討します。この障害の完了条件は、目的の指紋が提示され認証されることです。

判断表

HostName または User が誤り — 宛先を直し、鍵状態は維持します。

切断前に意図しない指紋が多数 — 1 鍵テスト後、限定 Host ブロックを設定します。

目的の 1 指紋でも拒否 — サーバー認可または署名診断へ移ります。

1 鍵テスト成功 — 他の ID を残し、有効設定を再検証します。

OpenSSH 以外または ssh_config 無視 — 製品固有のエージェントと選択制御を特定します。