Ошибка аутентификации SSH-ключа при подключении ведомого устройства Mac Hudson к ведущему устройству Linux

Хорошо, у меня Hudson (v1.393) работает на виртуальной машине Ubuntu, и все работает нормально. Однако я пытаюсь добавить подчиненное устройство Mac к мастеру Ubuntu, и у меня возникло несколько проблем.

Я настроил ключи SSH, чтобы из командной строки виртуальная машина Ubuntu могла использовать ssh с помощью ключа для пользователя с именем hudson на Mac.

В конфигурации ведомого устройства Hudson я выбрал «Запускать ведомые агенты на машинах Unix через SSH» и ввел IP-адрес хоста, имя пользователя на ведомом устройстве и расположение моего файла закрытого ключа на ведущем устройстве (который был добавлен в файл авторизованных ключей на ведомом устройстве).

Однако ведущему устройству не удается подключиться к ведомому. Глядя на журнал (ниже), он пытается аутентифицироваться с помощью пароля.

Является ли это запасным вариантом для неудачной попытки SSH на основе ключа?
Хадсон пытается аутентифицироваться только с использованием пароля, и мне нужно изменить что-то еще, чтобы заставить его использовать файл ключей, который определен в конфигурации?
Разве на макинтоше просто невозможно запустить подчиненные агенты по ssh? (Я знаю, что название этого типа метода запуска ведомого устройства явно указывает на Unix, но я думал (читай: надеясь), что он будет работать и с OS X)

Журнал

[01/14/11 10:38:07] [SSH] Opening SSH connection to 10.0.1.188:22.
[01/14/11 10:38:07] [SSH] Authenticating as hudson/******.
java.io.IOException: Password authentication failed.
at com.trilead.ssh2.auth.AuthenticationManager.authenticatePassword(AuthenticationManager.java:319)
at com.trilead.ssh2.Connection.authenticateWithPassword(Connection.java:314)
at hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:565)
at hudson.plugins.sshslaves.SSHLauncher.launch(SSHLauncher.java:179)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:184)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
Caused by: java.io.IOException: Authentication method password not supported by the server at this stage.
at com.trilead.ssh2.auth.AuthenticationManager.authenticatePassword(AuthenticationManager.java:289)
... 9 more
[01/14/11 10:38:07] [SSH] Connection closed.

Если кому-то удавалось покорять подобный тип настройки раньше, или есть какие-либо советы или идеи, я был бы очень благодарен! Спасибо


macos ssh master slave hudson
person mattbilson    schedule 17.01.2011    source источник
comment
Вы пробовали без закрытого ключа и с паролем? Посмотрите, подключается ли он с помощью этого метода ..   -  person Sagar    schedule 17.01.2011
comment
Вы пытались подключиться к ящику OS X из виртуальной машины с помощью jsut ssh, чтобы узнать, включен ли ключ аутентификации? OS X box - это серверная или клиентская версия? Вы оставили пароль пустым при генерации ключа?   -  person prodigitalson    schedule 17.01.2011
comment
@Sagar: Просто попробовал использовать пароль, а не ключ. Не повезло, те же сообщения в журнале.   -  person mattbilson    schedule 17.01.2011
comment
@prodigitalson: ssh из командной строки на виртуальной машине Ubuntu на Mac работает нормально. Изначально у меня был пароль для ключа ssh, но затем я создал новый ключ без пароля, так как подумал, что это может быть проблемой. Машина OS X - это не серверная версия, а стандартная OS X 10.6.6.   -  person mattbilson    schedule 17.01.2011

Ответы (3)


arrow_upward
16
arrow_downward

Недавно я столкнулся с той же проблемой, пытаясь запустить агент на компьютере Mac OS X 10.6 с использованием SSH.

Чтобы аутентификация по паролю работала, вам нужно отредактировать / etc / sshd_config на клиентском узле, установив PasswordAuthentication yes

На панели управления Hudson отключите узел, убедитесь, что в конфигурации указаны действительные имя пользователя и пароль, и запустите агент. Также убедитесь, что каталог Remote FS root принадлежит пользователю сборки, от имени которого вы подключаетесь.

Для аутентификации ssh без пароля сначала проверьте, от имени какого пользователя работает мастер Hudson. Предположим, что это tomcat55. Сгенерируйте пару открытого / закрытого ключей SSH (с пустой кодовой фразой), затем убедитесь, что пользователь Hudson может подключиться.

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/tomcat55/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/tomcat55/.ssh/id_rsa.
Your public key has been saved in /home/tomcat55/.ssh/id_rsa.pub.

$ # authorize the hudson master on the hudson node
$ scp /home/tomcat55/.ssh/id_rsa.pub hudson@macnode:~/.ssh/authorized_keys
$ # test the connection
$ ssh -i /home/tomcat55/.ssh/id_rsa hudson@macnode

На Mac-узле Hudson файл / etc / sshd_config должен разрешить доступ без пароля.

Protocol 2
PubkeyAuthentication yes

В конфигурации узла очистите поле пароля и установите поле закрытого ключа (в этом примере это /home/tomcat55/.ssh/id_rsa). Теперь у вас должна быть возможность запустить агент:

[01/19/11 22:38:44] [SSH] Opening SSH connection to macnode:22.
[01/19/11 22:38:44] [SSH] Authenticating as hudson with /home/tomcat55/.ssh/id_rsa.
[01/19/11 22:38:45] [SSH] Authentication successful.
person Ronen Botzer    schedule 20.01.2011
comment
Спасибо, Ронен! Парольная аутентификация работает нормально. Однако, если я удалю пароль и полагаюсь на ключ ssh, он все равно не работает, и Хадсон, похоже, все еще полагается на пароль - [01.02.11 13:11:45] [SSH] Аутентификация как mattbilson / ** ****. Это что-то еще в моем sshd_config? У меня есть RSAAuthentication да, PubkeyAuthentication да, AuthorizedKeysFile .ssh / authorized_keys - person mattbilson; 20.01.2011
comment
Подключаемый модуль SSH возвращается к паролю, если он не может использовать закрытый ключ для входа в узел. Я бы оставил поле пароля пустым, пока вы пытаетесь во всем разобраться, чтобы убедиться, что это не PasswordAuthentication, который его пропускает. Кроме того, происходит ssh -i KEYFILE USER @ HOST. Если вы можете сделать это вручную как пользователь hudson, то Hudson также сможет это сделать. Можете ли вы отправить su пользователю hudson, а затем попробовать ssh из командной строки? Если есть какие-то проблемы, вы, скорее всего, найдете их таким образом. - person Ronen Botzer; 20.01.2011
comment
Вот и все! Hudson работает от пользователя hudson, но я работаю на машине ubuntu как другой пользователь. И у Хадсона не было разрешений для моего ключевого файла. Итак, теперь я создал ключ для пользователя hudson и добавил его на Mac. Оказывается, это была довольно простая ошибка. Спасибо за информацию о том, чем Хадсон на самом деле занимался Ронен! - person mattbilson; 20.01.2011
comment
@RonenBotzer: У вас такая же проблема, пожалуйста, взгляните на нее. stackoverflow.com/questions/44194994/ опубликован вопрос. - person Swift; 26.05.2017
comment
@mattbilson: Имея такую ​​же проблему, пожалуйста, посмотрите, stackoverflow.com/questions/44194994/ - person Swift; 26.05.2017

arrow_upward
2
arrow_downward

Проверьте файл /var/log/auth.log на машине Ubuntu. Держу пари, вам нужно chmod 700 в каталог .ssh пользователя hudson.

person Satya    schedule 17.01.2011
comment
Только что попробовал 700-ing этот файл, теперь разрешения -rwx ------. По-прежнему не повезло. - person mattbilson; 17.01.2011

arrow_upward
1
arrow_downward

Я думаю, что первый ответ (выбранный) - отличный ответ, но я нашел случай, когда это не единственное решение.

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

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

person newz2000    schedule 14.08.2012