Вопрос или проблема
У меня есть сервер для тестирования и производственный сервер, и я запускаю идентичные Bitbucket Pipelines, куда отправляю команды через SSH. К сожалению, мой pipeline для производственного сервера постоянно завершается неудачей с:
Проверка ключа хоста не удалась.
Я попробовал всё, права на папки, воссоздание ключей, ничего не работает.
Наконец, добавив -v к вызову ssh, я считаю, что на шаг ближе, но всё равно потерян.
На моем тестовом сервере я вижу что-то вроде этого:
debug1: Хост '$STAGING_SERVER' известен и соответствует RSA ключу хоста.
debug1: Найден ключ в /root/.ssh/known_hosts:4
debug1: ssh_rsa_verify: подпись верна
и остальная часть сборки проходит безупречно.
На моем производственном сервере, однако, я вижу следующее:
debug1: Хост '$PRODUCTION_SERVER' известен и соответствует RSA ключу хоста.
debug1: Найден ключ в /root/.ssh/known_hosts:5
debug1: read_passphrase: не удается открыть /dev/tty: Нет такого устройства или адреса
debug1: permanently_drop_suid: 0
ssh_askpass: exec(/usr/bin/ssh-askpass): Нет такого файла или директории
Проверка ключа хоста не удалась.
Таким образом, похоже, что ключ найден на моем производственном сервере, но по какой-то причине на производственном сервере вызывается read_passphrase. Я только что создал новый ключ id_rsa и id_rsa.pub, без пароля, так почему же мой производственный сервер пытается вызвать read_passphrase? Мои ssh_config и sshd_config на обоих серверах идентичны – проверено с помощью diff.
Другой способ взглянуть на это заключается в том, что ssh_rsa_verify вызывается немедленно на тестовом сервере, тогда как на производственном сервере вызывается read_passphrase.
Любая помощь здесь будет очень полезна, это сводит меня с ума!
Аллилуйя! Проблема решена! 🥳
Часы потрачены впустую по самой простой причине…
Я заметил в полном выводе ssh -v на производственном сервере, что Bitbucket выводил что-то вроде этого:
debug1: Подключение к $PRODUCTION_SERVER [12.345.567.890] порт 22.
в то время как вывод для тестирования был:
debug1: Подключение к $STAGING_SERVER [$STAGING_SERVER] порт 22.
Это означает, что статический IP был точным значением этой переменной репозитория. (Bitbucket удаляет секретные логи, поэтому они выглядят таким образом).
Я понял, что неправильно установил переменную репозитория PRODUCTION_SERVER как псевдоним для IP-адреса (то есть myserver.com), тогда как она должна быть точным IP-адресом. Изменение этого значения в переменных репозитория на IP-адрес решило проблему! Судя по всему, использование имени псевдонима не является достаточно точным соответствием, чтобы SSH был удовлетворён.
Ответ или решение
Проблема, с которой вы столкнулись, связана с установлением SSH-соединения между вашим Bitbucket Pipeline и производственным сервером. Судя по вашим исходным сообщениям, основная причина сбоя заключалась в некорректной настройке переменной окружения PRODUCTION_SERVER, что привело к неудаче при проверке соответствия ключей. Давайте подробнее рассмотрим, почему это произошло и как избежать подобных ошибок в будущем.
Проблема с подключением по SSH
Когда вы выполняете команду SSH, она пытается установить соединение с удаленным сервером, используя предоставленные хост-ключи для аутентификации. Если ключи не совпадают, SSH выдает сообщение об ошибке, и вы наблюдаете поведение, когда read_passphrase вызывается даже при отсутствии пароля на ключе. Однако, как выяснилось, в вашем случае это не было связано с паролем на ключе, а скорее с неправильным разрешением имени хоста.
Разбор логов
Как вы наверняка заметили, разница в логах между staging и production-серверами указывает на важный момент:
- На staging-сервере вывод содержал переменную имени хоста, в то время как на production-сервере отображался статический IP-адрес.
Это могло означать, что конфигурация known_hosts не была должным образом настроена для соответствия имени хоста, предоставленному Bitbucket.
Корректная настройка переменных окружения
Чтобы исправить эту проблему, вы правильно сделали, обновив переменную PRODUCTION_SERVER, указав в ней именно IP-адрес, а не псевдоним. Это обеспечило точное соответствие между хостом и его ключом, что в итоге разрешило проблему с Host key verification failed.
Проблемы с ошибками аутентификации SSH часто вызваны неправильными разрешениями имен хостов, что может быть особенно важно в ситуациях, связанных с равноправной аутентификацией и безопасными соединениями.
Рекомендации по предотвращению проблем
-
Используйте IP-адреса: Всегда уточняйте, что вы используете IP-адреса для настройки SSH в автоматизированной среде, такой как Bitbucket Pipelines, чтобы избежать проблем с разрешением имен.
-
Обновление known_hosts: Убедитесь, что файл
known_hostsна всех серверах содержит правильные ключи для использования. Если вы изменили адреса, не забудьте обновить файл. -
Логи и отладка: Всегда включайте режим отладки (
-v) для получения более подробной информации о процессе подключения, что может значительно облегчить диагностику. -
Проверка переменных: Регулярно проверяйте и валидируйте значения переменных среды, особенно в контексте CI/CD, чтобы убедиться, что они настроены верно.
Таким образом, вы успешно исправили свою проблему с подключением, и ваша настойчивость и внимательность к деталям помогли вам добиться успеха. Надеюсь, эти рекомендации помогут вам и другим избежать похожих проблем в будущем.