Недопустимая ключевая ошибка SSH в амулете при использовании его с МААСОМ
Это - вывод амулета от чистой установки с 2 узлами, которые все выполнение 12,04 начальных загрузок амулета - заканчивает без ошибок и выделяет машину пользователю, но все еще никакая радость после среды амулета - не уничтожает и восстанавливает с различными пользователями и различными узлами.
root@cloudcontrol:/storage# juju -v status
2012-06-07 11:19:47,602 DEBUG Initializing juju status runtime
2012-06-07 11:19:47,621 INFO Connecting to environment...
2012-06-07 11:19:47,905 DEBUG Connecting to environment using node-386077143930...
2012-06-07 11:19:47,906 DEBUG Spawning SSH process with remote_user="ubuntu" remote_host="node-386077143930" remote_port="2181" local_port="57004".
The authenticity of host 'node-386077143930 (10.5.5.113)' can't be established.
ECDSA key fingerprint is 31:94:89:62:69:83:24:23:5f:02:70:53:93:54:b1:c5.
Are you sure you want to continue connecting (yes/no)? yes
2012-06-07 11:19:52,102 ERROR Invalid SSH key
2012-06-07 11:19:52,426:18541(0x7feb13b58700):ZOO_INFO@log_env@658: Client environment:zookeeper.version=zookeeper C client 3.3.5
2012-06-07 11:19:52,426:18541(0x7feb13b58700):ZOO_INFO@log_env@662: Client environment:host.name=cloudcontrol
2012-06-07 11:19:52,426:18541(0x7feb13b58700):ZOO_INFO@log_env@669: Client environment:os.name=Linux
2012-06-07 11:19:52,426:18541(0x7feb13b58700):ZOO_INFO@log_env@670: Client environment:os.arch=3.2.0-23-generic
2012-06-07 11:19:52,426:18541(0x7feb13b58700):ZOO_INFO@log_env@671: Client environment:os.version=#36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012
2012-06-07 11:19:52,428:18541(0x7feb13b58700):ZOO_INFO@log_env@679: Client environment:user.name=sysadmin
2012-06-07 11:19:52,428:18541(0x7feb13b58700):ZOO_INFO@log_env@687: Client environment:user.home=/root
2012-06-07 11:19:52,428:18541(0x7feb13b58700):ZOO_INFO@log_env@699: Client environment:user.dir=/storage
2012-06-07 11:19:52,428:18541(0x7feb13b58700):ZOO_INFO@zookeeper_init@727: Initiating client connection, host=localhost:57004 sessionTimeout=10000 watcher=0x7feb11afc6b0 sessionId=0 sessionPasswd=<null> context=0x2dc7d20 flags=0
2012-06-07 11:19:52,429:18541(0x7feb0e856700):ZOO_ERROR@handle_socket_error_msg@1579: Socket [127.0.0.1:57004] zk retcode=-4, errno=111(Connection refused): server refused to accept the client
2012-06-07 11:19:55,765:18541(0x7feb0e856700):ZOO_ERROR@handle_socket_error_msg@1579: Socket [127.0.0.1:57004] zk retcode=-4, errno=111(Connection refused): server refused to accept the client
- Я попробовал многочисленные способы создать ключи с ssh-keygen-t rsa-b 2048, ssh-keygen-t rsa, ssh-keygen, и я попытался добавить тех, которые к веб-странице конфигурации МААСА, но всегда получают тот же результат.
- Я добавил соответствующий открытый ключ впоследствии к
~/.ssh/authorized_keys - Я могу также ssh к узлу, но поскольку меня не попросили дать ему имя пользователя или пароль или настроить любой вид учетной записи, я не могу вручную ssh в узел. Установка узла все обрабатывается сервером Мааса. Это походит на простую ошибку рассмотрения неправильного ключа или взгляда в неправильных местах, только другие предложения, которые я могу найти, состоят в том, чтобы уничтожить среду и восстановить (но это не работало многочисленные времена теперь), или оставьте это, создают экземпляр, после того как узел включился, но я уехал в течение нескольких часов и уехал в течение ночи для создания без удачи.
4 ответа
Убедитесь, что вы генерируете ключи SSH на том же хосте, на котором вы используете juju, и добавьте открытую половину ваших ключей SSH на этом компьютере в MAAS (попробуйте: ls ~/.ssh/*.pub, чтобы найти их все). Не должно быть необходимости вручную вставлять ключи в ~/.ssh/authorized_keys.
Начало работы с руководством Джуджу может помочь, если вы этого не видели.
Решение, которое я нашел, состоит в том, чтобы установить пароль для недавно загруженных узлов, а затем вручную вставить ключи SSH в каждый из них. Чтобы установить загрузочный пароль для пользователя Ubuntu, убедитесь, что следующие строки в /var/lib/cobbler/kickstarts/maas.preseed:
d-i passwd/make-user boolean true
d-i passwd/user-fullname ubuntu
d-i passwd/username string ubuntu
d-i passwd/user-password-crypted password <CRYPTED PASSWORD>
Как только это будет сделано, вы можете использовать ssh ubuntu @ и использовать пароль, указанный в зашифрованной строке пароля (самый простой способ - использовать его из файла / etc / shadow, который вы уже знаете) для входа в систему. Затем вы можете вставить свои открытые ключи SSH в ~ ubuntu / .ssh / authorized_keys и ~ root / .ssh / авторизованные ключи.
Обратите внимание, что это обходной путь - после того, как вы выполните ssh-keygen, MaaS должен либо извлечь id_rsa.pub из вашего каталога .ssh, либо из веб-интерфейса MaaS, где пользователь может указать открытый ключ в своем профиле. Независимо от того, что я пробовал, эти ключи не распространяются, поэтому я нашел обходной путь.
Еще один способ - просто добавить ключ .pub к .ssh / авторизованному ключу вашего узла MaaS и затем скопировать его на каждый из узлов в MaaS:
for i in `cobbler system list |grep -v default`;
do j=`cobbler system dumpvars --name "${i}" | grep hostname |grep -v duplicate |cut -f 2 -d \:`;
scp ~/.ssh/authorized_keys ubuntu@${j}:.ssh/authorized_keys;
done
Это позволит вам просто неоднократно принимайте ошибки сертификата SSH и введите пароль в зашифрованной строке, чтобы заполнить весь ваш MaaS открытым ключом SSH.
Убедитесь, что у вас достаточно времени для установки узла после начальной загрузки; установка Ubuntu может занять 10 секунд. Появляются сообщения об ошибках, указывающие на то, что juju пытается подключиться к машине, на которой еще не запущен sshd, что для меня указывает на то, что, вероятно, установщик все еще работает.
Я столкнулся с той же проблемой. Два дня назад я начал искать ответ, и самая важная вещь, которую я обнаружил, заключается в следующем:
При запуске «статус juju» вы можете столкнуться с ошибкой «Недействительный ключ SSH»
Наиболее вероятный источник этой ошибки - то, что узлы, которые запустили juju, еще не закончили загрузку и установку. Это может произойти, когда часы на узле слишком далеко не синхронизированы для проверки OAuth, что приводит к истечению времени ожидания узла при попытке загрузки из службы метаданных и в конечном итоге продолжает загружаться в приглашение на вход в систему без запуска Juju preseed .
Попробуйте проверить часы на узле и сбросить их, если они сильно отличаются от часов сервера MAAS.
Это действительно решило эту проблему. Я запустил ntpdate на своем сервере MAAS и установил новый узел, теперь отлично работает!