Fastlane match не может подключиться через SSH

Существующие решения

Я тщательно искал SO и Github, прежде чем задать свой вопрос. Ни в одной из существующих тем нет рабочих решений для нашей установки.

Конфигурация

У нас есть Jenkins + Fastlane, настроенный на удаленной машине с macOS. Предполагается, что Fastlane match получает учетные данные для подписи (сертификат + профиль обеспечения) из выделенного репозитория через SSH.

Проблема

Соединение SSH не работает (зависает). Вывод консоли Дженкинса:

INFO [2019-04-09 14:09:29.05]: Cloning remote git repo...
INFO [2019-04-09 14:09:29.05]: If cloning the repo takes too long, you can use the `clone_branch_directly` option in match.
INFO [2019-04-09 14:09:29.05]: [36m$ git clone ssh://[email protected]:xxxx/cert/ios-certificates-profiles.git /var/folders/_redacted_[0m
INFO [2019-04-09 14:09:29.07]: ▸ [35mCloning into '/var/folders/_redacted_'...[0m
INFO [2019-04-09 14:09:29.19]: ▸ [35mThe authenticity of host '[xxx.xx.x.xxx:xxxx]:xxxx ([xxx.xx.x.xxx:xxxx]:xxxx)' can't be established.[0m
INFO [2019-04-09 14:09:29.19]: ▸ [35mRSA key fingerprint is _REDACTED_.

Выполнение команды «git clone ssh://[email protected]:xxxx/…» из терминала на том же компьютере:

  • успешно клонирует репозиторий
  • добавляет хост в файл known_hosts

Тем не менее Дженкинс продолжает висеть на команде матча на скоростной полосе. Есть идеи, почему Дженкинс не может подключиться к репозиторию через SSH? Что мне не хватает?

Изменить

Добавление опции clone_branch_directly к команде match не дает результата, команда все равно зависает.


person mmvie    schedule 09.04.2019    source источник
comment
Следили ли вы инструкциям Если клонирование репозитория занимает слишком много времени, вы можете использовать параметр clone_branch_directly в матче. совет, который он дает вам уже? Можете ли вы добавить полный вывод, который вы получаете от запуска команды вручную, для сравнения?   -  person janpio    schedule 09.04.2019


Ответы (3)


Попробуйте сначала ту же операцию с Jenkins, запущенную в среде, где для переменной GIT_SSH_COMMAND установлено значение ssh -vvv: это даст вам полные трассировки, когда Git попытается клонировать с URL-адресом SSH.

OP mmvie подтверждает в комментариях:

Добавление подробного ведения журнала в SSH показало, что Jenkins запускался как sudo.
Запуск Jenkins не как sudo и указание на правильные ключи SSH решили проблему.


Другие возможности:

проблема fastlane 5473 упоминает проблему known_hosts, но если отпечаток удаленного сервера уже добавлен (при условии, что ваш Jenkins работает с той же учетной записью, что и ваш собственный сеанс оболочки), затем проверьте, защищен ли ваш закрытый ключ парольной фразой:

FWIW, когда я ssh-add -D, а затем запускаю fastlane certs (который запускает совпадение), я получаю точно такое же поведение. Он зависает при клонировании удаленного репозитория git... Это ожидаемое поведение. 'ssh-add' все исправляет.

То же самое в выпуске Fastlane 7482:

Выяснил это ... был на новом ящике и не добавил мой ключ в ssh-agent.

ssh-add -K ~/.ssh/id_rsa

Другая возможность: проблема с полосой пропуска 11732:

Я тоже сталкиваюсь с этим на CircleCi 2.0

Установка этого в моей конфигурации среды на Circle 2.0 помогает

environment:
  TERM: xterm-256color

Поэтому проверьте значение переменной окружения $TERM.

person VonC    schedule 16.04.2019
comment
Добавление подробного ведения журнала в SSH показало, что Jenkins запускался как sudo. Запуск Jenkins не как sudo и указание на правильные ключи SSH решили проблему. Спасибо! - person mmvie; 18.04.2019
comment
@mmvie Отлично! я включил ваш комментарий в ответ для большей наглядности. - person VonC; 18.04.2019

Я решил аналогичную проблему с

ssh-keyscan myserver.com >> ~/.ssh/known_hosts

person Jaime Agudo    schedule 28.02.2020
comment
добавление bitbucket.org к известным хостам решено, спасибо. - person yildirimatcioglu; 22.12.2020
comment
огромное спасибо!! - person Enrique Arevalo; 25.04.2021

У меня зависла задача на Circle CI на шаге матча на скоростной трассе. Причина в том, что я выполнил шаг «оформить заказ» в Linux и заставил его перебросить рабочее пространство на macos vm. Таким образом, команда «checkout» была новее настроена на машине macos, и ssh не знал имени хоста битбакета.

Это было решено путем добавления дополнительной команды «checkout» в задание macos env. Это займет немного времени, потому что все синхронизируется по рабочей области.

person Gosha Egorian    schedule 09.08.2019