Вход по SSH-ключу работает через раз или вовсе спрашивает пароль: ключ назван нестандартно, и клиент его не предлагает

Что было. Две похожие истории. В первой пользователь сгенерировал пару ключей с именем id_colibri, добавил публичную часть на сервер, и вход по ключу то проходил, то запрашивал пароль. Во второй после обновления Debian с 12 на 13 перестал работать вход с сервера резервного копирования на сервер данных по ключу id_ed25519-mimas.

Причина. Клиент OpenSSH без явных указаний пробует только ключи со стандартными именами: id_rsa, id_ecdsa, id_ed25519 (и их варианты). Файл с другим именем он не трогает. В ssh -v это видно как Will attempt key: /home/user/.ssh/id_ed25519 для файла, которого нет, и полное отсутствие упоминания вашего ключа. Почему «через раз»: где-то ключ был загружен в агент (ssh-add) и предлагался оттуда; после перезагрузки или в новой сессии агент пуст, и клиент падал на пароль. Оба автора подтвердили решение.

Как правильно.

  1. Разово: ssh -i ~/.ssh/id_colibri user@host.
  2. Постоянно, в ~/.ssh/config:
    Host nas
        HostName nas.example.local
        User monuser
        IdentityFile ~/.ssh/id_colibri
        IdentitiesOnly yes
    
    IdentitiesOnly yes заодно запрещает перебирать все ключи агента, что спасает от «Too many authentication failures» на серверах с малым MaxAuthTries.
  3. Для автоматизации (cron, скрипты бэкапа) всегда -i или IdentityFile: там нет агента и нет интерактивного запроса пароля, задание просто падает.
  4. Альтернатива из второго обсуждения: переименовать ключ в стандартное имя. Работает, но при нескольких серверах с разными ключами конфиг удобнее.

Как убедиться, что дело в этом. ssh -v user@host 2>&1 | grep -E 'Will attempt|Offering|Server accepts': если вашего файла нет среди Will attempt, клиент его не знает. При успехе появится Server accepts key: /home/user/.ssh/id_colibri и Authenticated to … using "publickey".

Про права. Если файл предлагается, но отвергается с Permissions … are too open, нужен chmod 600 на приватный ключ и 700 на ~/.ssh. На стороне сервера authorized_keys должен принадлежать пользователю и быть 600; иначе sshd в режиме StrictModes его игнорирует (отдельный разбор).

Параметр описан в документации OpenSSH.