「Too many authentication failures」の解決 - 鍵の送りすぎ

2026-06-06 読了時間: 約11分 難易度: 中級

「Too many authentication failures」とは何が起きているのか？

結論: サーバが許す認証試行回数（MaxAuthTries、既定6回）を、正しい鍵に到達する前に使い切って切断された状態。鍵が間違っているのではなく「送りすぎ」が原因。

このエラーは SSH の接続自体は成立し、サーバの sshd まで会話が届いている。ネットワークの問題でも、鍵そのものが無効なわけでもない。

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures
Disconnected from 203.0.113.10 port 22

sshd は1接続あたりの認証試行回数に上限（MaxAuthTries、デフォルト 6）を設けている。公開鍵認証では、クライアントが鍵を1つ提示するたびに1回の試行としてカウントされる。ssh-agent に大量の鍵を抱えていると、ssh は接続先が受け付けるかどうかに関係なく手持ちの鍵を順に提示し、正しい鍵にたどり着く前に上限へ達する。

まず何を確認すべきか？

結論: ssh -v で Offering public key: の行数を数える。切断前に何個の鍵を提示しているかが、そのまま原因の証拠になる。

最初にやることは「自分がいくつ鍵を送っているか」の可視化だ。

$ ssh -v user@server.example.com

注目する行:

debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:...
debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:...
debug1: Offering public key: ssh-ed25519 SHA256:... agent
debug1: Offering public key: ssh-rsa SHA256:... agent
...
Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

Offering public key が6回前後並んだ直後に切断されていれば、原因は確定だ。提示している鍵が多すぎて、正しい鍵を出す前に MaxAuthTries を超えている。

なぜ鍵を送りすぎると拒否されるのか？

結論: sshd は1接続で許す認証試行を MaxAuthTries 回に制限する。公開鍵は提示するだけで1回消費するため、鍵が多いと「正しい鍵を試す前に」枠が尽きる。

仕組みを整理すると次のとおり。

1. クライアントは利用可能な鍵を順番にサーバへ提示する。
2. サーバは提示された鍵が authorized_keys にあるか確認し、無ければ「次へ」と促す。
3. この1往復が1試行としてカウントされる。
4. 試行回数が MaxAuthTries に達した時点で、サーバは認証成功を待たずに切断する。

つまり、鍵が10個あって正解が9番目にある場合、6回目で打ち切られて正解に届かない。これが「送りすぎ」の正体だ。

今すぐ繋ぐ応急処置は？

結論: -o IdentitiesOnly=yes と -i 鍵 を併用して、提示する鍵を1つだけに限定する。これで試行回数が1回に収まり、その場で接続できる。

$ ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@server.example.com

IdentitiesOnly=yes が要だ。これが無いと、-i で鍵を指定しても ssh は ssh-agent の鍵を追加で提示してしまい、提示回数は減らない。ここが最大の落とし穴になる。

正しい鍵が分からない場合は、-v を併用して1つずつ試す。

$ ssh -v -o IdentitiesOnly=yes -i ~/.ssh/id_rsa user@server.example.com

Authentication succeeded (publickey) が出れば、その鍵が正解だ。次の手順で恒久設定に落とし込む。

~/.ssh/config で恒久対処するには？

結論: 接続先ごとに IdentityFile と IdentitiesOnly yes を ~/.ssh/config に書く。以後は鍵が自動で1つに絞られ、コマンドにオプションを付ける必要がなくなる。

Host myserver
    HostName server.example.com
    User user
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

これで ssh myserver だけで、指定した鍵のみを提示する接続になる。

複数のサーバを使い分けるなら、ホストごとにブロックを分ける。

Host prod
    HostName prod.example.com
    User deploy
    IdentityFile ~/.ssh/id_prod
    IdentitiesOnly yes

Host gitlab
    HostName gitlab.example.com
    User git
    IdentityFile ~/.ssh/id_gitlab
    IdentitiesOnly yes

ssh-agent の鍵を整理するには？

結論: ssh-add -l で登録数を確認し、多すぎるなら ssh-add -D で一旦全削除して必要な鍵だけ入れ直す。agent の肥大化が「送りすぎ」の根本原因になりやすい。

まず現状を確認する。

$ ssh-add -l

256 SHA256:... user@host (ED25519)
3072 SHA256:... old-key (RSA)
256 SHA256:... another (ED25519)
...

ここに6個以上並んでいれば、IdentitiesOnly を使わない限りどのサーバでも試行枠を食い潰す。不要な鍵を消す。

# 全削除して入れ直す
$ ssh-add -D
$ ssh-add ~/.ssh/id_ed25519

特定の鍵だけ外す場合:

$ ssh-add -d ~/.ssh/id_rsa

サーバ側で MaxAuthTries を調整すべきか？

結論: サーバを管理しているなら MaxAuthTries を上げて回避できるが、総当たり耐性が下がる対症療法。原則はクライアント側で鍵を絞るのが正攻法。

サーバの実効値は sshd -T で確認する。

$ sudo sshd -T | grep -i maxauthtries

maxauthtries 6

どうしても多数の鍵を提示する運用が避けられない場合のみ、/etc/ssh/sshd_config で値を上げる。

MaxAuthTries 10

$ sudo systemctl reload ssh

再発を防ぐチェックリスト

結論: 「提示鍵を1つに絞る」が解決の本質。config の IdentitiesOnly、agent の整理、サーバ設定の確認を順に潰せば再発しない。

• [ ] ssh -v で Offering public key の数が MaxAuthTries（既定6）を超えていないか
• [ ] 応急処置として -o IdentitiesOnly=yes -i 鍵 で接続できるか
• [ ] ~/.ssh/config の対象 Host に IdentityFile と IdentitiesOnly yes を書いたか
• [ ] ssh-add -l の登録鍵が多すぎないか（不要なら ssh-add -D）
• [ ] 鍵が自動で戻る場合、AddKeysToAgent や起動スクリプトを確認したか
• [ ] サーバ管理者の場合、sshd -T で maxauthtries の実効値を確認したか