Сбой проверки ключа хоста с использованием mpi4py

Question

Я создаю MPI-приложение, используя mpi4py (1.3.1) и openmpi (1.8.6-1) в Arch Linux ARM (если быть более точным, на кластере Raspberry Pi). Я успешно выполнил свою программу на 3 узлах (4 процесса), и при попытке добавить новый узел происходит следующее:

Host key verification failed.
--------------------------------------------------------------------------
ORTE was unable to reliably start one or more daemons.
This usually is caused by:

* not finding the required libraries and/or binaries on
  one or more nodes. Please check your PATH and LD_LIBRARY_PATH
  settings, or configure OMPI with --enable-orterun-prefix-by-default

* lack of authority to execute on one or more specified nodes.
  Please verify your allocation and authorities.

* the inability to write startup files into /tmp (--tmpdir/orte_tmpdir_base).
Please check with your sys admin to determine the correct location to use.

*  compilation of the orted with dynamic libraries when static are required
  (e.g., on Cray). Please check your configure cmd line and consider using
  one of the contrib/platform definitions for your system type.

* an inability to create a connection back to mpirun due to a
  lack of common network interfaces and/or no route found between
  them. Please check network connectivity (including firewalls
  and network routing requirements).

Самое смешное, что с ssh-ключами все в порядке, так как я использую одни и те же узлы (я могу удалить любую запись файла хоста, добавить новый узел, и он будет работать, поэтому я почти уверен, что проблема не в с неправильно настроенной настройкой ssh. Это происходит только тогда, когда я использую 5 процессов).

Может ли это быть какой-то ошибкой в ​​библиотеке?

Вот мой файл хоста

192.168.1.26 slots=2
192.168.1.188 slots=1
#192.168.1.202 slots=1 If uncommented and run with -np 5, it will raise the error
192.168.1.100 slots=1

Заранее спасибо!

Answer 1

У меня была такая же проблема на мини-кластере Linux x86_64 под управлением Fedora 22 и OpenMPI 1.8. Я мог подключиться по SSH к любой из моих 5 машин с моего запускающего компьютера, но когда я попытался запустить MPI с 3 или более узлами, это вызвало бы ошибку аутентификации. И, как вы, казалось, что 3 - это волшебное число, и оказывается, что оно есть. OpenMPI использует запуск на основе дерева, поэтому, когда у вас более двух узлов, один или несколько промежуточных узлов выполняют ssh. В моем случае я не использовал установку без пароля. У меня был идентификатор SSH на машине запуска, который я добавил в свою цепочку ключей. Он смог запустить первые два узла, потому что у меня была эта аутентифицированная личность в моей цепочке ключей. Затем каждый из этих узлов пытался запустить больше, и у этих узлов не было аутентифицированного ключа (мне нужно было бы добавить его на каждом из них).

Таким образом, решение, похоже, переходит к настройке идентификации SSH без пароля, но вы, очевидно, должны быть осторожны, как вы это делаете. Я создал определенную личность (пару ключей) на моей машине запуска. Я добавил ключ к своим авторизованным ключам на узлах, которые я хочу использовать (это легко, поскольку все они используют NFS, но вы можете вручную распределить ключ один раз, если вам нужно). Затем я изменил свою конфигурацию SSH, чтобы использовать эту идентификацию без пароля при попытке перейти на мои узлы. Мой ~/.ssh/config выглядит так:

Host node0
    HostName node0
    IdentityFile ~/.ssh/passwordless_rsa
Host node1
    HostName node1
    IdentityFile ~/.ssh/passwordless_rsa
...

Я уверен, что есть какой-то способ масштабировать это для N узлов с подстановочными знаками. Или вы можете рассмотреть возможность изменения файла идентификации по умолчанию на системном уровне в системном конфигурационном файле ssh (держу пари, что аналогичная опция доступна там).

И это помогло. Теперь я могу раскрутить все 5 узлов без проблем аутентификации. Недостаток в моем мышлении состоял в том, что узел запуска будет запускать все другие узлы, но этот запуск на основе дерева означает, что вам нужно объединить логины, что вы не можете сделать с идентификатором, аутентифицированным по ключевой фразе, поскольку у вас никогда не будет возможности аутентифицировать его.

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