# Too many authentication failures: SSH ran out of tries

LLMS index: [llms.txt](/en/llms.txt)

---

`Received disconnect from 10.0.0.5 port 22:2: Too many authentication failures` followed by `Permission denied (publickey)` is not a broken server, and it is not necessarily a wrong password. The client **spent the attempt budget** while walking agent keys and never reached the method you meant to use.

The budget is `MaxAuthTries` on the server (**6** by default). Each public key offered is one try. Five keys in `ssh-agent` plus one more wrong key — the connection dies before the right key or a password prompt.

## Why this happens

SSH asks the server which methods it accepts, then the client walks its own order. `publickey` is first by default. While the agent keeps offering keys, the server is already counting failures.

| You wanted | What actually happened |
| --- | --- |
| Key login | The key is missing from `authorized_keys`, it is not in the agent, or it is fifth in line — the limit hits first |
| Password login | The server advertised `publickey`, the client started the key walk, the password prompt never appeared |
| PAM / external password | The client sends `password`, the server wants `keyboard-interactive` |

A file sitting in `~/.ssh` is not enough: OpenSSH offers **agent identities**, not “the file you had in mind”. What will actually be sent:

```bash
ssh-add -l
```

Empty agent or the wrong key — read `-vvv` instead of guessing.

## Client log first

Debug level 3 shows the method order and every key offered:

```bash
ssh -vvv deploy@10.0.0.5
```

Look for:

- `Authentications that can continue` — what the server allowed;
- `Offering public key` / `get_agent_identities` — which keys go out;
- `Too many authentication failures` — attempt budget, not “wrong password”.

Typical picture: the agent hands over `id_rsa`, `id_ed25519`, a GitLab key, a bastion key — four rejects, the fifth is still wrong, the sixth is no longer accepted.

## Stop offering every key

`IdentitiesOnly yes` stops the client from mixing in every agent identity. After that, only `IdentityFile` or `-i` is used.

Per host, not in the global `/etc/ssh/ssh_config`:

```sshconfig
Host prod
    HostName 10.0.0.5
    User deploy
    IdentitiesOnly yes
    IdentityFile ~/.ssh/id_ed25519_prod
```

One-shot:

```bash
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod deploy@10.0.0.5
```

`-vvv` should then show a single `Offering public key`. If `too many` turns into `Permission denied (publickey)`, the walk is over and the key was simply rejected: it is not in `authorized_keys`, or it is the wrong file.

> [!NOTE]
> `IdentitiesOnly` without `IdentityFile` keeps the default `id_ed25519` / `id_rsa` in the home directory and **does not** dump the whole agent. For a stand with its own key, always name the file.

## Password when the agent is full

The client will not ask for a password until `publickey` is exhausted. Turn keys off and put password first:

```bash
ssh -o PubkeyAuthentication=no \
    -o PreferredAuthentications=password \
    -o PasswordAuthentication=yes \
    deploy@10.0.0.5
```

In `~/.ssh/config`:

```sshconfig
Host prod-password
    HostName 10.0.0.5
    User deploy
    PubkeyAuthentication no
    PasswordAuthentication yes
    PreferredAuthentications password
```

On Ubuntu and anywhere the password goes through PAM, the server often advertises `keyboard-interactive`, not `password`. The command above then fails silently. Switch the method:

```bash
ssh -o PubkeyAuthentication=no \
    -o PreferredAuthentications=keyboard-interactive \
    deploy@10.0.0.5
```

```sshconfig
Host prod-password
    HostName 10.0.0.5
    User deploy
    PubkeyAuthentication no
    PreferredAuthentications keyboard-interactive
```

Which method the server actually offers is the `Authentications that can continue` line in `-vvv`.

## What to check on the server

You need another channel: hypervisor console, VNC, serial. Otherwise you are stuck in the same error you are fixing.

**Logs.** On Ubuntu 24.04 the unit is `ssh` (`sshd` is an alias). For rejected-key detail, raise verbosity:

```bash
# /etc/ssh/sshd_config or a drop-in under /etc/ssh/sshd_config.d/
LogLevel VERBOSE
```

```bash
sudo systemctl restart ssh
sudo journalctl -u ssh -e
# if rsyslog is installed:
sudo tail -f /var/log/auth.log
```

The log shows which key was rejected and whether `MaxAuthTries` was reached.

**Permissions.** With `StrictModes yes` (the default) `sshd` silently ignores files that are too open:

```bash
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
# the home directory must not be group/other-writable
```

The public key is one line in `authorized_keys`; the matching private key is the one in `IdentityFile`.

**Attempt limit.** A fat agent and many keys per host can justify raising the cap (this weakens brute-force protection):

```text
MaxAuthTries 10
```

Better not to raise it: shrink the client with `IdentitiesOnly` and one `IdentityFile` per `Host`.

## Short checklist

1. `ssh -vvv` — how many keys went out and which method remained.
2. `ssh-add -l` — what sits in the agent; do not offer the rest.
3. In `~/.ssh/config` for the host: `IdentitiesOnly yes` and an explicit `IdentityFile`.
4. Need a password — `PubkeyAuthentication no` and the method the server printed in debug (`password` or `keyboard-interactive`).
5. From the server console: `journalctl -u ssh`, `~/.ssh` / `authorized_keys` modes, `LogLevel VERBOSE` if needed.

A “too many” error is almost always on the client: too many keys for one login. The server only counts to six and closes the session.