Eu repliquei isso duas ou três vezes, então estou supondo que há algo errado com o que estou fazendo.
Aqui estão os meus passos:
10 minutos depois, quando a instância deve estar em funcionamento, minha conexão de terminal mostra:
stead:~ stead$ ssh -v -i Dropbox/SteadCloud3.pem [email protected]
OpenSSH_5.6p1, Op'enSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to 54.201.200.208 [54.201.200.208] port 22.
debug1: connect to address 54.201.200.208 port 22: Connection refused
ssh: connect to host 54.201.200.208 port 22: Connection refused
stead:~ stead$
Tudo bem, eu entendo que o endereço IP público pode mudar, então, checando o console de gerenciamento do EC2, eu confirmo que é o mesmo. Esquisito. Apenas por diversão, eu tento conectar-me com o hostname do DNS público: ec2-54-201-200-208.us-west-2.compute.amazonaws.com. Nenhum dado, mesmo resultado.
Mesmo usando o cliente Connect via Java SSH incorporado ao console do EC2, recebo o Connection Refused.
Eu verifiquei os grupos de segurança. Esta instância está no grupo launch-wizard-4. Olhando para a configuração de entrada para este grupo, a porta 22 é permitida a partir de 0.0.0.0/0, de modo que deve estar em qualquer lugar. Eu sei que estou atingindo minha instância e esse é o grupo de segurança certo, porque não consigo executar ping na instância. Se eu ativar o ICMP para esse grupo de segurança, de repente meus pings passarão.
Encontrei algumas outras postagens na Internet com mensagens de erro semelhantes, mas a maioria parece ser facilmente resolvida ajustando as configurações do firewall. Eu tentei alguns desses, sem sorte.
Eu estou supondo que há um simples passo EC2 que eu estou perdendo. Obrigado por qualquer ajuda que você possa dar, e eu estou feliz em fornecer mais informações ou testar mais!
Atualização - aqui estão os meus registros do sistema no console do Amazon EC2: link
Tive um comportamento semelhante hoje em dia na minha instância do ec2 e localizei o seguinte: quando eu faço %código% a máquina trava e eu tenho que reiniciá-lo manualmente a partir do console de gerenciamento aws quando eu faço %código% Ele reinicia bem. Aparentemente, "now" não é uma opção válida para reinicialização, como apontado aqui link
pensamentos?
Em postagem no fórum do desenvolvedor da AWS sobre este tópico :
Try stopping the broken instance, detaching the EBS volume, and attaching it as a secondary volume to another instance. Once you've mounted the broken volume somewhere on the other instance, check the /etc/sshd_config file (near the bottom). I had a few RHEL instances where Yum scrogged the sshd_config inserting duplicate lines at the bottom that caused sshd to fail on startup because of syntax errors.
Once you've fixed it, just unmount the volume, detach, reattach to your other instance and fire it back up again.
Vamos detalhar isso, com links para a documentação da AWS:
cd /etc/ssh sudo nano sshd_config ctrl-v um monte de vezes para chegar ao final do arquivo ctrl-k todas as linhas na parte inferior mencionando "PermitRootLogin sem senha" e "UseDNS não" ctrl-x e Y para salvar e sair do arquivo editado cd /etc sudo nano rc.local ctrl-x e Y para salvar e sair do arquivo editado Pode não ajudar na situação, mas eu vi alguns casos em que a reinicialização no EC2 fica 'paralisada'. Se você fizer um "reset" na VM e, em seguida, recuperar os logs do sistema, isso poderá alterar o comportamento. Certifique-se de que os logs sejam do segundo boot e não do primeiro - eles tendem a atrasar as atualizações.
Outra coisa a verificar é ter certeza de que a instância está respondendo no IP. Parece que você está recebendo uma conexão recusada acima, o que parece que a instância está ativa, mas o SSH não está em execução ou tem firewall, mas certifique-se de que a instância foi totalmente reinicializada.
Você também pode tentar abrir todas as portas de um sistema de teste e ver o que o 'nmap' mostra: quaisquer outros serviços que estejam respondendo na instância.
Clique com o botão direito do mouse no nome da instância e clique em "Alterar grupos de segurança". Certifique-se de que o grupo de segurança que você criou, que permite que qualquer pessoa de qualquer lugar para a porta 22, seja verificado e aplicado a essa instância.
Eu peguei este problema depois de fazer sudo reboot now via SSH no meu servidor EC2 rodando o Ubuntu 14.04. Funcionou bem depois de reiniciar novamente usando o Console de Gerenciamento do EC2.
No meu caso, eu configurei um grupo de segurança para permitir conexões da porta 22 somente do meu IP. Alguns dias depois, meu ISP mudou meu endereço IP, por isso o grupo de segurança precisa de atualização.
Eu tive um problema semelhante, minha instância do Amazon Linux do EC2 não estava mais acessível depois de executar sudo reboot .
Nenhum comando de acesso SSH, parar / iniciar / reinicializar do console de administração da Amazon também não me deu nenhum resultado.
Eu finalmente consegui reiniciar minha instância criando uma imagem por meio do console da Amazon. O processo de criação de imagens parece corrigir o estado da instância.
Espero que ajude;)
Eu tive o mesmo problema depois de executar o comando baunilha sudo reboot . Descobri que consegui resolver o problema parando completamente (não reinicializando) a minha AMI usando o console da AWS e, em seguida, iniciando o backup.
Por alguma razão, reiniciar a AMI a partir do console da AWS, como ao clicar na ação de reinicialização, em vez de parar e iniciar a instância, resolveu o problema não .
Como mencionado, você provavelmente mexeu com o / etc / fstab /
Eu tive esse problema. Primeiro você tem que adicionar novamente o volume em / dev / sda1 como a mensagem de aviso diz.
Então eu não pude ssh. Percebi que tinha que adicionar o outro volume que criei e que consertava o problema do ssh.
Então você pode acessar e corrigir o fstab de volta ao original.
Tags ssh amazon-ec2 cloud