Erro de chave SSH inválido no juju ao usá-lo com o MAAS

4

Esta é a saída do juju de uma instalação limpa com 2 nós executando 12.04 juju bootstrap - finaliza sem erros e aloca a máquina para o usuário, mas ainda não há alegria após o ambiente de juju - destruir e reconstruir com diferentes usuários e nós diferentes .

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
  • Eu tentei várias maneiras de criar as chaves com ssh-keygen -t rsa -b 2048, ssh-keygen -t rsa, ssh-keygen e tentei adicioná-las à página de configuração da web do MAAS, mas sempre mesmo resultado.
  • Eu adicionei a chave pública apropriada depois ao ~/.ssh/authorized_keys
  • Eu também posso ssh para o nó, mas como não me pediram para fornecer um nome de usuário ou senha ou configurar qualquer tipo de conta, não consigo fazer ssh manualmente no nó. A configuração do nó é toda manipulada pelo servidor maas. Parece um erro simples de olhar para a chave errada ou procurar nos lugares errados, apenas outras sugestões que posso encontrar são para destruir o ambiente e reconstruir (mas isso não funcionou muitas vezes agora) ou deixá-lo para construir a instância uma vez que o nó tenha ligado, mas eu saí por algumas horas e saí da noite para construir sem sorte.
por Captain T 07.06.2012 / 12:34

4 respostas

2

A solução que criei é definir uma senha para os nós recém-inicializados e inserir manualmente as chaves SSH em cada um deles. Para definir uma senha de boot para o usuário do ubuntu, assegure-se de que as seguintes linhas estejam disponíveis em /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>

Uma vez feito isto, você pode usar o ssh ubuntu @ e usar a senha especificada na string de senha criptografada (a maneira mais fácil é usar um de um arquivo / etc / shadow que você já conhece) para efetuar login. Chaves públicas SSH sob ~ ubuntu / .ssh / authorized_keys e ~ root / .ssh / chaves autorizadas.

Observe que esta é uma solução alternativa - uma vez que você ssh-keygen, o MaaS deve estar puxando o id_rsa.pub do seu diretório .ssh ou do MaaS WebUI, onde o usuário pode especificar uma chave pública em seu perfil. Não importa o que eu tentei, essas chaves não são propagadas, então eu criei a solução.

Outra fraude é simplesmente adicionar a chave .pub ao .ssh / authorized_keys do seu nó do MaaS e, em seguida, scp-lo para cada um dos nós no 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

Isso permite que você apenas aceite repetidamente os erros do certificado SSH e digite a senha na string criptografada para preencher todo o seu MaaS com a chave pública SSH.

    
O
por cheez0r 20.06.2012 / 16:43
2

Verifique se você está gerando suas chaves SSH no mesmo host em que está usando o juju e adicione a metade pública de suas chaves SSH nessa máquina no MAAS (tente: ls ~/.ssh/*.pub para encontrá-las todos). Não deve haver necessidade de colocar as chaves manualmente em ~/.ssh/authorized_keys .

O guia primeiros passos com o Juju pode ajudar se você ainda não viu isso.

    
por Gavin Panella 20.06.2012 / 18:25
1

Estou enfrentando o mesmo problema. Há dois dias comecei a procurar uma resposta e a coisa mais importante que descobri é esta:

  

Ao executar "status juju", você pode encontrar um erro que diz   "Chave SSH inválida"

     

A fonte mais provável deste erro é que os nós que juju   iniciado ainda não terminou a inicialização e instalação ainda. Isso pode   acontecer quando o relógio no nó está muito fora de sincronia para o OAuth   verificação para o trabalho, o que resulta no tempo limite do nó ao tentar   para baixar do serviço de metadados e, eventualmente, continua a inicialização   para um prompt de login sem executar o Juju preseed.

     

Tente verificar o relógio no nó e redefina-o se for muito diferente   do relógio do servidor MAAS.

     

link

Isso realmente resolveu esse problema. Eu corri o ntpdate no meu servidor MAAS e instalei o novo nó, agora funciona muito bem!

    
por guimaluf 12.07.2012 / 21:21
0

Certifique-se de deixar bastante tempo para o nó ser instalado após o bootstrap; Pode levar 10 segundos para concluir a instalação do Ubuntu. As mensagens de erro aparecem para indicar que o juju está tentando se conectar a uma máquina que ainda não está executando o sshd, o que para mim indica que o instalador provavelmente ainda está em execução.

    
por Gavin Panella 20.06.2012 / 17:31

Tags