SSH не использует pubkey, хотя настроен правильно.

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение
Заключение

Вопрос или проблема

Я пытаюсь настроить свой pubkey, и все работает нормально, за исключением первого подключения в день, которое продолжает запрашивать пароль явно.

Это не большая проблема для меня, однако я бы хотел создать некоторые сервисы, которые будут подключаться к этому серверу, и думаю, что запрос пароля все испортит.

Если я запускаю ssh -vv ... во время подключения, когда оно запрашивает пароль, я получаю:

OpenSSH_9.8p1, LibreSSL 3.3.6
debug1: Чтение конфигурационных данных /Users/my_username/.ssh/config
debug1: /Users/my_username/.ssh/config строка 79: Применение настроек для acquario3
debug1: Чтение конфигурационных данных /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config строка 21: включить /etc/ssh/ssh_config.d/* не найдено ни одного файла
debug1: /etc/ssh/ssh_config строка 54: Применение настроек для *
debug1: Поставщик аутентификаторов $SSH_SK_PROVIDER не определен; отключение
debug1: Выполнение прокси-команды: exec ssh -W other_host:22 host
debug1: файл идентификации /Users/my_username/.ssh/id_rsa тип 0
debug1: файл идентификации /Users/my_username/.ssh/id_rsa-cert тип -1
debug1: файл идентификации /Users/my_username/.ssh/id_ecdsa тип -1
debug1: файл идентификации /Users/my_username/.ssh/id_ecdsa-cert тип -1
debug1: файл идентификации /Users/my_username/.ssh/id_ecdsa_sk тип -1
debug1: файл идентификации /Users/my_username/.ssh/id_ecdsa_sk-cert тип -1
debug1: файл идентификации /Users/my_username/.ssh/id_ed25519 тип 3
debug1: файл идентификации /Users/my_username/.ssh/id_ed25519-cert тип -1
debug1: файл идентификации /Users/my_username/.ssh/id_ed25519_sk тип -1
debug1: файл идентификации /Users/my_username/.ssh/id_ed25519_sk-cert тип -1
debug1: файл идентификации /Users/my_username/.ssh/id_xmss тип -1
debug1: файл идентификации /Users/my_username/.ssh/id_xmss-cert тип -1
debug1: файл идентификации /Users/my_username/.ssh/id_dsa тип -1
debug1: файл идентификации /Users/my_username/.ssh/id_dsa-cert тип -1
debug1: Локальная строка версии SSH-2.0-OpenSSH_9.8
[email protected]'s пароль:

Конфигурация SSH следующая (я запускаю other_host, но это ProxyCommand запрашивает пароль, соединение от host к other_host работает всегда нормально):

Host host
  HostName host.it
  Port 22
  User user
  IdentityFile ~/.ssh/id_ed25519
  ServerAliveInterval 60
  ServerAliveCountMax 3
  TCPKeepAlive yes
  
Host other_host
  HostName other_host
  Port 22
  User user
  ProxyCommand ssh -W %h:%p host
  ServerAliveInterval 60
  ServerAliveCountMax 3
  TCPKeepAlive yes

Обновление:
кажется, сервер использует kerberos с билетами сеанса, поэтому, вероятно, домашняя папка недоступна при входе в систему. Поэтому я подумал добавить krenew -b -K 604800 в .bashrc, однако я получаю:

$ krenew -b -K 604800

krenew: ошибка чтения кеша билетов: Кеш удостоверений не найден (имя файла: /tmp/krb5cc_15521)

Ответ или решение

Проблема, описанная в вашем вопросе, связана с тем, что SSH соединение не использует публичный ключ для аутентификации при первом подключении за день, и вместо этого запрашивает пароль. Это особенно критично в ситуациях, когда необходимо использовать службы, зависящие от беспарольного входа на сервер. Рассмотрим основные причины и возможные решения этой проблемы, исходя из предоставленной информации.

Теория

Основной принцип работы SSH заключается в использовании криптографической пары, состоящей из закрытого и открытого ключей, что позволяет организовать безопасное подключение к серверу. Когда клиент устанавливает соединение с сервером, он обычно пытается аутентифицироваться с использованием открытого ключа. Если это не удается, сервер запрашивает пароль.

Ваш случай усложняется вовлечением Kerberos, а именно использованием kerberos билетов, что может ограничивать доступ к файловой системе в момент первоначального подключения. Kerberos — это протокол сетевой аутентификации, разработанный для обеспечения безопасного способа аутентификации пользователя. Файл кэша полномочий (credentials cache) может не быть доступным в момент первой попытки аутентификации, что вынуждает SSH обращаться к паролю.

Пример

Разберем конкретные моменты, выявленные в вашем отладочном выводе SSH (ssh -vv):

Отсутствие разрешения на использование некоторых файлов ключей. Хотя указываются различные файлы ключей (.rsa, .ecdsa, .ed25519 и т. д.), сервер может не видеть нужного ключа или воспринимать его как неподходящий. В случае с вашим подключением ключ id_ed25519 используется, так как он указан в конфигурации, но проверка других может задерживать первое соединение.
На уровне ProxyCommand. Во время первой попытки соединения, которая инициируется через ProxyCommand ssh -W %h:%p host, происходит сбой, вероятно, из-за ограничения доступа к билету Kerberos, как вы заметили. Это вызывает запрос пароля.
Kerberos и доступность домашней директории. Сообщение об ошибке krenew указывает на отсутствие кэша полномочий в момент вызова, что может происходить при первой попытке взаимодействия с сервером.

Применение

Чтобы решить эту проблему, рассмотри несколько подходов:

Убедитесь в правильности настройке Kerberos. Убедитесь, что билет Kerberos корректно получен до попытки первый подключения к SSH. Для этого можно использовать команды kinit или рассмотреть настройки kssh-agent, которые могут кэшировать билеты и предоставлять их при необходимости.
Обновление .bashrc. Вместо вызова krenew постарайтесь удостовериться, что билет Kerberos доступен раньше, чем взаимодействие с SSH. Возможно, стоит рассматривать опцию запуска kinit с cron для автоматического обновления билета перед попыткой первого соединения, используя @reboot или любой другой подходящий планировщик.
Оптимизация настроек SSH-клиента. Проверьте правильность конфигурации SSH в файле ~/.ssh/config. Например, убедитесь, что для ключа используется правильный формат и что он доступен (в идеале начиная только с нужного ключа).
Проверка прав доступа и санкций. Убедитесь, что домашняя директория и сами файлы открытого ключа имеют корректные права доступа. Неправильные права доступа могут помешать правильному чтению и использованию ключей.
Логирование активности. Чтобы иметь полное понимание того, что происходит при первой авторизации, включите расширенное логирование сервера SSH (LogLevel DEBUG3) и изучите возможные ошибки и предупреждения, выдаваемые сервером.

Заключение

Комбинация факторов, включая использование ProxyCommand, участие Kerberos и необходимость первого инициирования соединения, требуют комплексного анализа и настройки. Утверждение контроля над методом аутентификации и корректное управление билетами Kerberos может устранить проблему запроса пароля и обеспечить бесперебойную работу сервисов, зависящих от автоматического подключения.