# Too many authentication failures: SSH исчерпал попытки

Индекс LLMS: [llms.txt](/llms.txt)

---

`Received disconnect from 10.0.0.5 port 22:2: Too many authentication failures` и следом `Permission denied (publickey)` — это не «сервер сломан» и не обязательно неверный пароль. Клиент **потратил лимит попыток**, пока перебирал ключи из агента, и до нужного метода так и не дошёл.

Лимит задаёт `MaxAuthTries` на сервере (по умолчанию **6**). Каждый предложенный публичный ключ — отдельная попытка. Пять ключей в `ssh-agent` плюс ещё один «не тот» — и соединение рвётся до пароля и до правильного ключа.

## Почему так выходит

SSH сначала спрашивает сервер, какие методы он принимает, затем клиент идёт по своему порядку. По умолчанию в начале стоит `publickey`. Пока агент совал ключи, сервер уже посчитал неудачи.

| Что хотели | Что произошло |
| --- | --- |
| Войти по ключу | Нужного ключа нет в `authorized_keys`, он не в агенте, или он пятый в очереди — лимит кончился раньше |
| Войти по паролю | Сервер объявил `publickey`, клиент начал перебор, приглашения пароля так и не было |
| Пароль из PAM / внешней службы | Клиент шлёт `password`, сервер ждёт `keyboard-interactive` |

Ключ «лежит в `~/.ssh`» недостаточно: OpenSSH предлагает **идентичности агента**, а не «файл, который вы имели в виду». Список того, что реально уйдёт на сервер:

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

Пустой агент или «ключ не тот» — смотреть `-vvv`, а не гадать.

## Сначала лог клиента

Третий уровень отладки показывает порядок методов и каждый предложенный ключ:

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

Искать:

- `Authentications that can continue` — что разрешил сервер;
- `Offering public key` / `get_agent_identities` — какие ключи уходят;
- `Too many authentication failures` — лимит попыток, не «пароль неверный».

Типичная картина: агент отдаёт `id_rsa`, `id_ed25519`, ключ от GitLab, ключ от bastion — четыре отказа, пятый ещё не тот, шестой уже не принимают.

## Не предлагать все ключи

`IdentitiesOnly yes` запрещает клиенту подмешивать все идентичности агента. Дальше работает только то, что задано через `IdentityFile` или `-i`.

На один хост, не в глобальный `/etc/ssh/ssh_config`:

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

Разово:

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

После этого в `-vvv` должен остаться один `Offering public key`. Если вместо `too many` пришло `Permission denied (publickey)` — перебор закончился, ключ просто не приняли: его нет в `authorized_keys` или не тот файл.

> [!NOTE]
> `IdentitiesOnly` без `IdentityFile` оставляет дефолтные `id_ed25519` / `id_rsa` в домашнем каталоге и **не** тащит весь агент. Для стенда с отдельным ключом всегда указывайте файл явно.

## Пароль, когда ключей много

Клиент не спросит пароль, пока не исчерпает `publickey`. Отключить ключи и поставить пароль первым:

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

В `~/.ssh/config`:

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

На Ubuntu и везде, где пароль идёт через PAM, сервер часто объявляет `keyboard-interactive`, а не `password`. Тогда предыдущая команда молча не сработает. Заменить метод:

```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
```

Какой метод сервер реально предлагает — снова строка `Authentications that can continue` в `-vvv`.

## Что смотреть на сервере

Нужен другой канал: консоль гипервизора, VNC, serial. Иначе вы в той же ошибке, что чините.

**Логи.** На Ubuntu 24.04 юнит называется `ssh` (алиас `sshd`). Для разбора неудачных ключей поднять подробность:

```bash
# /etc/ssh/sshd_config или drop-in в /etc/ssh/sshd_config.d/
LogLevel VERBOSE
```

```bash
sudo systemctl restart ssh
sudo journalctl -u ssh -e
# если стоит rsyslog:
sudo tail -f /var/log/auth.log
```

В логе будет, какой ключ отвергли и дошли ли до `MaxAuthTries`.

**Права.** При `StrictModes yes` (дефолт) `sshd` молча игнорирует слишком открытые файлы:

```bash
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
# домашний каталог не должен быть writable для group/other
```

Публичный ключ — одна строка в `authorized_keys`, парный приватный — тот, что в `IdentityFile`.

**Лимит попыток.** Если агент толстый, а ключей на хост много, можно поднять порог (это ослабляет защиту от перебора):

```text
MaxAuthTries 10
```

Надёжнее не поднимать лимит, а сузить клиент: `IdentitiesOnly` + один `IdentityFile` на `Host`.

## Короткий чеклист

1. `ssh -vvv` — сколько ключей ушло и какой метод остался.
2. `ssh-add -l` — что лежит в агенте; лишнее не предлагать.
3. В `~/.ssh/config` для хоста: `IdentitiesOnly yes` и явный `IdentityFile`.
4. Нужен пароль — `PubkeyAuthentication no` и тот метод, который сервер написал в debug (`password` или `keyboard-interactive`).
5. С консоли сервера: `journalctl -u ssh`, права `~/.ssh` и `authorized_keys`, при необходимости `LogLevel VERBOSE`.

Ошибка про «too many» почти всегда на клиенте: слишком много ключей на одну попытку входа. Сервер лишь считает до шести и закрывает сессию.