Недавно я сконструировал небольшой кластер Beowulf из нескольких старых компьютеров, работающих под управлением Linux Ubuntu 12.04 LTS, и следовал инструкциям на этой странице:

http://byobu.info/article/Building_a_simple_Beowulf_cluster_with_Ubuntu/

До сих пор все шло хорошо, как nfs и пинг других узлов, но теперь я не могу заставить ssh работать без пароля. Я потратил много часов, читая другие страницы о людях со схожей проблемой, но ни одна из вещей, которые им помогли, мне не помогла (переход в режим 600, редактирование файла sshd_configure и т . Д.).

в конце концов я просто перешел к остальным шагам, надеясь, что смогу просто ввести пароль при выполнении задачи, и это сработает, если задача выполняется только на одном компьютере (потому что он запрашивает пароль у mpiuser @ node1 и я можно просто ввести его), но как только я пытаюсь запустить задачу (упомянутую ниже в этом документе программу cpi для тестирования кластера) на более чем одном узле, он (что не удивительно) запрашивает пароль для обоих узлов, что то же самое, и я ввожу его, но затем он просто зависает, я думаю, что это как-то связано с тем, как он просит (он просто перечисляет их: пароль для mpiuser @ node1: пароль для mpiuser @ node2: пароль для mpiuser @ node3: и т. д.)

Я даже пытался удалить и переустановить ssh, но ничего не произошло, команда ssh-keygen, кажется, работает нормально (она говорит все, что, как говорят, все остальные), но потом ничего не делает. Мне удалось заставить ssh работать с паролем, потому что я обнаружил, что пароль ssh по умолчанию является паролем root, поэтому я просто изменил его, но в остальном команда ssh-keygen, похоже, ничего не делает.

Есть идеи?

--РЕДАКТИРОВАТЬ--

После ввода 

"ssh -v mpiuser@node1" it says:

      master@master:~$ su mpiuser

      **Password:** 

      mpiuser@master:/home/master$ cd

      mpiuser@master:~$ ssh -v mpiuser@node1

    OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012

    debug1: Reading configuration data /etc/ssh/ssh_config

    debug1: /etc/ssh/ssh_config line 19: Applying options for *

    debug1: Connecting to node1 [192.168.0.201] port 22.

    debug1: Connection established.

    debug1: identity file /home/mpiuser/.ssh/id_rsa type 1

    debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048

    debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048

    debug1: identity file /home/mpiuser/.ssh/id_rsa-cert type -1

    debug1: identity file /home/mpiuser/.ssh/id_dsa type -1

    debug1: identity file /home/mpiuser/.ssh/id_dsa-cert type -1

    debug1: identity file /home/mpiuser/.ssh/id_ecdsa type -1

    debug1: identity file /home/mpiuser/.ssh/id_ecdsa-cert type -1

    debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1

    debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*

    debug1: Enabling compatibility mode for protocol 2.0

    debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1

    debug1: SSH2_MSG_KEXINIT sent

    debug1: SSH2_MSG_KEXINIT received

    debug1: kex: server->client aes128-ctr hmac-md5 none

    debug1: kex: client->server aes128-ctr hmac-md5 none

    debug1: sending SSH2_MSG_KEX_ECDH_INIT

    debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

    debug1: Server host key: ECDSA 54:0e:8b:52:4d:41:08:fe:0b:bc:95:e5:93:42:59:40

    debug1: Host 'node1' is known and matches the ECDSA host key.

    debug1: Found key in /home/mpiuser/.ssh/known_hosts:1

    debug1: ssh_ecdsa_verify: signature correct

    debug1: SSH2_MSG_NEWKEYS sent

    debug1: expecting SSH2_MSG_NEWKEYS

    debug1: SSH2_MSG_NEWKEYS received

    debug1: Roaming not allowed by server

    debug1: SSH2_MSG_SERVICE_REQUEST sent

    debug1: SSH2_MSG_SERVICE_ACCEPT received

    debug1: Authentications that can continue: publickey,password

    debug1: Next authentication method: publickey

    debug1: Offering RSA public key: /home/mpiuser/.ssh/id_rsa

    debug1: Authentications that can continue: publickey,password

    debug1: Trying private key: /home/mpiuser/.ssh/id_dsa

    debug1: Trying private key: /home/mpiuser/.ssh/id_ecdsa

    debug1: Next authentication method: password

    mpiuser@node1's password:
|источник

5 ответов5

1

Ну, эти строки:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/mpiuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/mpiuser/.ssh/id_dsa
debug1: Trying private key: /home/mpiuser/.ssh/id_ecdsa
debug1: Next authentication method: password

скажем вам, что сервер разрешает входы на основе публичных ключей и паролей, поэтому клиент предлагает 3 открытых ключа (id_rsa, id_dsa и id_ecdsa), а сервер отклоняет все три, поэтому он возвращается к аутентификации по паролю.

Если вы ожидаете, что один из этих ключей будет работать, вам нужно посмотреть на сервер и понять, почему он их отклоняет. Посмотрите файл authorized_keys на сервере и убедитесь , что он имеет правильные открытые ключи , соответствующие частные ключи на клиенте, и убедитесь , что он имеет необходимые разрешения - должно принадлежать пользователю , вы каротажным как (mpiuser?) и не доступен для записи кем-либо еще.

|источник
1

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

Вы можете взглянуть на команду, это простой скрипт.

|источник
1

У меня та же проблема. Проверьте ваши права доступа к файлам и каталогам на клиентском и удаленном

 chmod 700 /home/user
 chmod 700 ~/.ssh
 chmod 600 ~/.ssh/authorized_keys
 chmod 600 ~/.ssh/config
 chmod 600 ~/.ssh/privatekey
 chmod 644 ~/.ssh/publickey.pub

Меня устраивает.

|источник
1

Я наконец-то понял! Оказывается, у ssh была проблема с правами доступа ко всей папке '/home/mpiuser', и поэтому он не работал ни для одного из узлов. Я просто отредактировал "StrictModes" на "no" в файле "sshd_config" и теперь все работает.

Спасибо всем за вашу помощь!

|источник
0

У меня та же проблема, что и у пользователя. Проблема вызвана настройкой разрешения действительно. До того, как все мои права доступа к папке '/home/xxx' были drwxrwxrwx (777). Сразу после того, как я изменил разрешение на drwx ------ (700). Оно работает! Примечания: предположим, что вы добавляете открытый ключ в авторизованные ключи и файл "sshd_config" правильный.

Дайте мне знать, если у вас есть какие-либо проблемы. :)

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .