VM do Azure: Conexão recusada pelo host

4

Recentemente, interrompi uma assinatura com 14 VMs e reiniciei alguns dias depois. Agora todas as minhas VMs estão funcionando bem, com exceção de 6 usadas para o MongoDB.

Eles respondem ao ping e, assim, são exibidos on-line no painel azul, mas não respondem a mais nada.

Eu tentei (de diferentes locais, dentro e fora da nuvem azul)

  • ssh: conecte-se à porta * do host *: Conexão recusada
  • telnet: não é possível conectar-se ao host remoto: conexão recusada
  • mongo: exceção: falha na conexão

As portas para ssh e mongo são abertas em azul. Tentei reiniciar as VMs algumas vezes através do painel azul, elas parecem reiniciar com êxito, mas ainda recusam todas as conexões.

Já procurei problemas similares e as melhores soluções que encontrei foram esperar ... o problema está acontecendo há sete dias e esperar não é mais uma opção.

    
por Simon Kérouack 22.01.2013 / 16:57

2 respostas

5

Existe uma solução melhor e mais rápida do que baixar / carregar o VHD. Como mencionado, o problema " foi reconhecido como uma nova linha ausente no arquivo sshd_config! "

0. No entanto, a primeira etapa deve ser diferente, porque senão você poderá perder seu IP atual do Cloud Service, se excluir a última VM nele - e no servidor da Web isso é um problema sério. Então, primeiro, crie uma nova VM na mesma região geográfica da VM com problemas, para que o serviço de nuvem tenha pelo menos uma VM em execução e o seu IP atual seja mantido.

  1. Delete the troubled VM but do not delete the associated disk. (You must delete the troubled VM to free up the lock on the associated disk which we would be using later). Note the name of the associated disk (AD).

  2. Select the new VM -> dashboard -> Attach -> "Attach Disk" (Note that the "Attach Disk" option is available only when the associated disk of the troubled VM has been freed up)

  3. Choose the correct AD name in the popup that opens up.

  4. Now SSH into the new VM and mount AD:

    sudo mkdir /tmp/dsk

    sudo mount /dev/sdc1 /tmp/dsk

(AD would typically be /dev/sdc1; if it isn't in your case, you can find it out by sudo cat /var/log/syslog | grep scsi and looking for the name preceding the message "Attached SCSI disk")

  1. sudo nano /tmp/dsk/etc/ssh/sshd_config

In our case, at the end of the file, we had a setting "UsePAM yesClientAliveInterval 180" - clearly a newline had been erroneously removed by the upgrade after "yes"! So we inserted the newline, saved the file and followed the steps below once sshd_config had been restored.

(You may also want to do a diff between /tmp/dsk/etc/ssh/ssh_config and /etc/ssh/sshd_config to see if any other configurations are off)

  1. Back to the Azure dashboard: Select the new VM -> dashboard -> Detach Disk and detach AD

  2. Fire up a new VM similar to the troubled VM: + New -> Compute -> Virtual Machine -> From Gallery -> My Disks -> AD (AD should show up here)

  3. That's it - hope SSH works now!

Resposta da fonte na parte inferior: link

    
por 09.06.2014 / 22:50
1

Muitas instalações do Azure foram duramente atingidas por esse bug no Ubuntu que faria as pessoas serem bloqueadas VMs devido a uma configuração defeituosa. O bug apareceria se você inicializasse as VMs de um estado interrompido ou as reiniciasse (após executar apt get upgrade ).

A correção para as instalações do Azure era fazer o download do VHD, montar o VHD como um disco, abrir o arquivo / etc / sshd_config e corrigir a linha defeituosa, depois reenviar o vhd.

    
por 24.05.2014 / 13:11

Tags