Вызов команды SSH от Jenkins

Пользователь jenkins по умолчанию — это системный пользователь, запускающий ваш экземпляр jenkins (главный или подчиненный). В зависимости от вашей установки этот пользователь может быть сгенерирован либо сценариями установки (deb/rpm/pkg и т.д.), либо администратором вручную. Это может или не может называться «Дженкинс».

Чтобы узнать, под каким пользователем работает ваш экземпляр jenkins, откройте http://$JENKINS_SERVER/systemInfo, доступный в меню «Управление Jenkins».

Там вы найдете свой user.home и user.name. Например. в моем случае на мастере Mac OS X:

user.home   /Users/Shared/Jenkins/Home/
user.name   jenkins

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

Альтернативой (которую я никогда не пробовал) было бы использование пользовательского задания jenkins для принятия этих отпечатков пальцев, например, выполнив следующую команду в задаче сборки SSH:

ssh -o "StrictHostKeyChecking no" your_remote_server

Этот последний совет, конечно, совершенно неприемлем с точки зрения безопасности :)

Поскольку при наличии множества подчиненных машин может быть трудно предугадать, на какой из них будет выполняться сборка, вместо явного вызова ssh я настоятельно рекомендую использовать существующие плагины Jenkins для SSH, выполняющего удаленные команды:

• Опубликовать через SSH — выполнять команды SSH или передавать файлы через SCP/SFTP.
• SSH — выполнение команд SSH.

Таким образом, можно выполнить «задание», которое записывает ключи хоста как константу, например:

echo "....." > ~/.ssh/known_hosts

просто заполните точки от ssh-keyscan -t rsa {ip} после того, как вы это проверите.

Правильно, конвейерные задания обычно используют пользователя jenkins, а это означает, что для этой учетной записи необходимо предоставить доступ SSH, чтобы он работал в конвейерных заданиях. У людей есть всевозможные сложные среды сборки, поэтому это кажется справедливым требованием.

Как указано в одном из ответов, каждая отдельная конфигурация может отличаться, поэтому проверьте в разделе «Информация о системе» или аналогичном разделе «Управление Jenkins» в веб-интерфейсе. Там должны быть user.home и user.name для домашнего каталога и имени пользователя соответственно. В моей установке CentOS это «/var/lib/jenkins/» и «jenkins».

Первое, что нужно сделать, это получить доступ к оболочке от имени пользователя jenkins в нашем случае. Поскольку это автоматически созданная учетная запись службы, оболочка не включена по умолчанию. Предполагая, что вы можете войти в систему как пользователь root или, предпочтительно, какой-либо другой пользователь (в этом случае вам нужно будет добавить sudo), переключитесь на jenkins следующим образом:

su -s /bin/bash jenkins

Теперь вы можете убедиться, что это действительно jenkins и что вы ввели правильный домашний каталог:

whoami
echo $HOME

Если они не соответствуют тому, что вы видите в конфигурации, не продолжайте.

Пока все хорошо, давайте проверим, какие ключи у нас уже есть:

ls -lah ~/.ssh

Могут быть только ключи, созданные с именем хоста. Посмотрите, можете ли вы их использовать:

ssh-copy-id user@host_ip_address

Если есть ошибка, вам может потребоваться сгенерировать новые ключи:

ssh-keygen

Примите значения по умолчанию и отсутствие парольной фразы, если вам будет предложено добавить новые ключи в домашний каталог без перезаписи существующих. Теперь вы можете снова запустить ssh-copy-id.

Это хорошая идея, чтобы проверить это с чем-то вроде

ssh user@host_ip_address ls

Если это работает, то должны работать ssh, scp, rsync и т. д. в заданиях Jenkins. В противном случае проверьте вывод консоли, чтобы увидеть сообщения об ошибках, и попробуйте те же самые команды в оболочке, как это было сделано выше.