Received disconnect from 172.22.0.4 port 22:2: Too many authentication failures appeared here when the SSH agent held eight keys and the one the server accepted was added last. The server cut the connection before a login. Name the right key and offer only that one: ssh -o IdentitiesOnly=yes -i ~/.ssh/devkey ....

This test used the command-line form of both options, with the same agent and keys that caused the error, and the login then worked.

The error

$ eval "$(ssh-agent -s)" >/dev/null; for i in 1 2 3 4 5 6 7; do ssh-add -q /root/.ssh/extra$i; done; ssh-add -q /root/.ssh/devkey; ssh-add -l | wc -l; ssh -o BatchMode=yes dev@sshd hostname; echo ssh-exit=$?; ssh -o BatchMode=yes -o IdentitiesOnly=yes -i /root/.ssh/devkey dev@sshd hostname; echo ssh-exit=$?; ssh-agent -k >/dev/null
8
Received disconnect from 172.22.0.4 port 22:2: Too many authentication failures
Disconnected from 172.22.0.4 port 22
ssh-exit=255
9aec0d80cdf9
ssh-exit=0
exit=0

Why it happens

The agent held eight keys (ssh-add -l | wc -l printed 8): seven extra test keys that the server did not know, added first, and devkey, the one in the user's authorized_keys, added last. The plain ssh command did not get to the right key: the server sent a disconnect with the text Too many authentication failures, and ssh exited with 255. The server ran sshd with its packaged configuration, where the MaxAuthTries line is commented out (#MaxAuthTries 6), and sshd -T reported maxauthtries 6, fewer than the eight keys in the agent.

The key's file name mattered in this test, not the order: both runs added the seven extra keys first and the right key last. In the first, the right key sat at the default path ~/.ssh/id_ed25519, which ssh tries by itself, and the login worked. The disconnect appeared once the right key was under a name ssh does not try by default, devkey.

The fix

The second ssh in the same command line above is the fix: -o IdentitiesOnly=yes -i /root/.ssh/devkey. With it, the same agent and the same eight keys, the login worked and printed the server's host name (its container id) with exit code 0. -i names the key, and with IdentitiesOnly=yes the other seven keys in the agent no longer stood in the way. Other ways, such as removing keys from the agent, were not tested here.

How it was reproduced

Reproduced inside ubuntu:24.04 containers on one user-defined Docker network on Docker engine 29.9.3, with OpenSSH_9.6p1 Ubuntu-3ubuntu13.20 as client and server. Seven throwaway keys were made with ssh-keygen -q -t ed25519 -N '' in the client container and loaded into an agent started with eval "$(ssh-agent -s)"; the server's test user dev knew only devkey. The containers and the network were removed afterwards.

Frequently asked

How do I fix Too many authentication failures in SSH?
Name the key and offer only that one: ssh -o IdentitiesOnly=yes -i path/to/key. In this test that logged in with the same agent that had caused the disconnect.
Why does SSH say Too many authentication failures with an agent?
In this test the agent held eight keys, the right one added last, and the server allowed six attempts (maxauthtries 6); it disconnected before a login.
What does IdentitiesOnly=yes do?
Together with -i it points the client at the named key. In this test it turned the disconnect into a working login with the same eight-key agent.

If ssh-add cannot reach an agent at all, see ssh-add: Could not open a connection to your authentication agent. More decoded errors in the Fixes category.