Conexão recusada no Ubuntu EC2 após a expansão do EBS

Question

O problema

Depois de iniciar uma instância do Ubuntu 14.04 EC2 com volumes HD expandidos, o ssh-it falha com Connection refused .

O processo de expansão do EBS

Uma das minhas máquinas Ubuntu 14.04 EC2 estava com pouco tamanho HD. Para resolver o problema, eu segui o manual da AWS sobre expansão em HD :

• Parou a máquina
• Detached os dois volumes
• Tomou um instantâneo de ambos os volumes
• Criaram volumes maiores a partir do instantâneo
• Anexou os novos volumes e iniciou a máquina

Além disso, aproveitei a oportunidade para adicionar um elástico IP para a máquina, se isso importa.

Depois de iniciar a máquina, constantemente recebo um erro Connection refused ao ssh-lo. Eu tentei o ssh de dentro do VPC para o IP privado e de fora. Usei o nome XX.X.XXX.XX IP e ec2-XX-X-XXX-XX.compute-1.amazonaws.com do DNS, e a chave .pem original que baixei da AWS após a criação, e a chave ssh que coloquei na .ssh/authorized_keys da máquina.

Eu recebo a mesma resposta:

ssh: connect to host ec2-XX-X-XXX-XX.compute-1.amazonaws.com port 22: Connection refused

Notas / O que eu tentei

• Eu conectei os volumes a outra instância e os verifiquei. Os arquivos estão lá.
• Tentei remover as linhas PermitRootLogin de /etc/ssh/sshd_config .
• Tentei conectar-me à máquina usando o cliente Java no console do EC2.
• Tentei conectar os volumes originais à máquina (antes da expansão). Eu ainda recebo Connection refused .
• O volume do EBS raiz está conectado em /dev/sda1 .

Solução

Atualizar : Problema resolvido . Muito obrigado a todos aqui!

    

Answer 1

Depois de uma sessão de suporte por chat com um suporte da AWS, descobrimos o problema.

Eu expandi dois volumes - /dev/sda1 e /dev/sdf . Quando conectei os volumes expandidos à máquina, o segundo foi anexado como um dispositivo diferente por algum motivo ( /dev/sdg , se minha memória me serve bem). Isso causou alguns problemas de inicialização e sshd nunca surgiu.

Quando o apoiador notou a discrepância, reinseri o volume em /dev/sdf e tudo funcionou bem.

Obrigado a todos pela ajuda - você tem sido ótimo!

    

Answer 2

apenas colocando este script hacky sujo, eu usei isso para depurar uma vez (você só precisa de python 2.xx instalado na máquina). Isso é sujo, mas pode ajudar mesmo assim!

Anexe e monte seu volume em outra VM e crie um arquivo, por exemplo, /whatever_mount_path/you_like/cgi-bin/cmd.py ('cgi-bin' é importante), com o conteúdo abaixo:

#!/usr/bin/env python
import os
br='<br/>'
print "Content-Type: text/html"
qs=os.environ['QUERY_STRING']
qs = {qs.split('=')[0]:qs.split('=')[1] for qs in   os.environ['QUERY_STRING'].split('&')}
print "cmd: ", qs ['cmd'], br*2
res = os.popen(qs['cmd']).read().replace('\n',br)
print res

depois, no "/etc/rc.local" do seu volume, adicione essas linhas:

cd /path_to_cgi-bin   #should be the path to your cgi-bin directory created above, without the mount path
nohup python -m CGIHTTPServer 8000 >> nohup.out 2>&1 &

reconecte seu volume à máquina inicial e inicialize-o. A partir de agora, você pode executar comandos do sistema a partir do seu navegador da Web, fornecendo seu cmd como uma string de consulta GET. por exemplo:

http://<YOUR VM IP>:8000/cgi-bin/cmd.py?cmd=netstat -ltpn | grep 22

, que será codificado pelo seu navegador como:

http://<YOUR VM IP>:8000/cgi-bin/cmd.py?cmd=netstat%20-ltpn%20|%20grep%2022

apenas certifique-se de que a porta 8000 esteja livre e que seu grupo de segurança esteja configurado corretamente

    

Answer 3

Connection refused geralmente significa que não há nada escutando no IP relevante: Porta. Normalmente, você pode confirmar isso usando o console OOB para efetuar login no sistema e executar o netstat, por exemplo

netstat -tunlp | grep :22

confirmaria que algo estava ou não escutando na porta 22.

Como você provavelmente não tem um console OOB, então você está preso com a montagem dos volumes em outra instância e cavando nos logs e arquivos de configuração.

Verifique se o seu sshd está configurado para escutar na (s) interface (s) correta (s) e na porta. Enquanto você está lá, aumente o LogLevel para que, da próxima vez que iniciar, você obtenha mais informações.

Pesquise todos os logs e veja se há alguma mensagem relevante.

Eu acho que você também pode adicionar uma tarefa cron ao sistema simplesmente editando um arquivo relevante e fazendo com que ele execute um comando netstat. Eu não uso o Ubuntu, mas algo como

@reboot root netstat -tunlp >>/tmp/netstat.out

em / etc / crontab (ou qualquer que seja o Ubuntu usa) teria um instantâneo do sistema depois que ele foi inicializado

Embora eu espere que isso dê uma mensagem de erro diferente, garanta que os grupos de segurança do EC2 estejam configurados corretamente.