Amazon EC2: sin SSH después del reinicio, conexión rechazada

He replicado esto dos o tres veces, así que supongo que hay algo mal con lo que estoy haciendo.

Aquí están mis pasos:

1. Inicie una nueva instancia a través de la consola de administración EC2 con: Ubuntu Server 13.10 - ami-ace67f9c (64 bits)
2. Iniciar con valores predeterminados (usando mi par de claves existente)
3. La instancia comienza. Puedo usar SSH usando Putty o el terminal Mac. ¡Éxito!
4. Reinicio la instancia

5. 10 minutos después, cuando la instancia debería estar nuevamente en funcionamiento, mi conexión de terminal muestra:

   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$
   

Bien, entiendo que la dirección IP pública puede cambiar, así que verificando la consola de administración EC2, verifico que sea la misma. Extraño. Solo por diversión, trato de conectarme con el nombre de host DNS público: ec2-54-201-200-208.us-west-2.compute.amazonaws.com. Sin dados, el mismo resultado.

Incluso usando el cliente Connect a través de Java SSH integrado en la consola EC2, obtengo Connection Refused.

Revisé los grupos de seguridad. Esta instancia está en el grupo launch-wizard-4. Mirando la configuración entrante para este grupo, el Puerto 22 está permitido desde 0.0.0.0/0, por lo que debería estar en cualquier lugar. Sé que estoy golpeando mi instancia y este es el grupo de seguridad correcto, porque no puedo hacer ping a la instancia. Si habilito ICMP para este grupo de seguridad, de repente mis pings pasan.

He encontrado algunas otras publicaciones en Internet con mensajes de error similares, pero la mayoría parece resolverse fácilmente ajustando la configuración del firewall. He probado algunos de estos, sin suerte.

Supongo que me falta un simple paso EC2. ¡Gracias por cualquier ayuda que pueda brindar, y me complace brindarle más información o realizar más pruebas!

Actualización: aquí están mis registros del sistema desde la consola Amazon EC2: http://pastebin.com/4M5pwGRt

Tuve un comportamiento similar hoy en mi instancia ec2, y rastreé el asunto hasta esto: cuando hago sudo reboot now la máquina se cuelga y tengo que reiniciarla manualmente desde la consola de administración de aws cuando lo hago, sudo reboot se reinicia bien. Aparentemente "ahora" no es una opción válida para reiniciar como se señala aquí /ubuntu/397502/reboot-a-server-from-command-line

pensamientos?

De la publicación del Foro de desarrolladores de AWS sobre este tema :

Intente detener la instancia rota, desconectando el volumen EBS y adjuntándolo como un volumen secundario a otra instancia. Una vez que haya montado el volumen roto en algún lugar de la otra instancia, verifique el archivo / etc / sshd_config (cerca de la parte inferior). Tuve algunas instancias de RHEL en las que Yum se burló del sshd_config insertando líneas duplicadas en la parte inferior que causaron que sshd fallara en el inicio debido a errores de sintaxis.

Una vez que lo haya arreglado, simplemente desmonte el volumen, desconecte, vuelva a conectar a su otra instancia y vuelva a encenderlo.

Analicemos esto, con enlaces a la documentación de AWS:

1. Detenga la instancia rota y desconecte el volumen EBS (raíz) yendo a la Consola de administración EC2, haciendo clic en "Elastic Block Store"> "Volumes", haciendo clic derecho en el volumen asociado con la instancia que detuvo.
2. Inicie una nueva instancia en la misma región y del mismo sistema operativo que la instancia rota, luego adjunte el volumen raíz EBS original como un volumen secundario a su nueva instancia . Los comandos en el paso 4 a continuación suponen que usted monta el volumen en una carpeta llamada "datos".
3. Una vez que haya montado el volumen roto en algún lugar de la otra instancia ,
4. revise el archivo "/ etc / sshd_config" para ver si hay entradas duplicadas emitiendo estos comandos:
   • cd /etc/ssh
   • sudo nano sshd_config
   • ctrl-v un montón de veces para llegar al final del archivo
   • ctrl-k todas las líneas en la parte inferior que mencionan "PermitRootLogin sin contraseña" y "UseDNS no"
   • ctrl-xy Ypara guardar y salir del archivo editado
5. @Telegard señala (en su comentario) que solo hemos solucionado el síntoma. Podemos solucionar la causa comentando las 3 líneas relacionadas en el archivo "/etc/rc.local". Entonces:
   • cd /etc
   • sudo nano rc.local
   • busque las líneas "PermitRootLogin ..." y elimínelas
   • ctrl-xy Ypara guardar y salir del archivo editado
6. Una vez que lo haya arreglado, simplemente desmonte el volumen ,
7. desconecte yendo a la Consola de administración EC2, haciendo clic en "Elastic Block Store"> "Volumes", haga clic derecho en el volumen asociado con la instancia que detuvo,
8. vuelva a conectar a su otra instancia y
9. encenderlo de nuevo .

Puede que no ayude a la situación, pero he visto algunos casos en los que un reinicio en EC2 se atasca. Si realiza un 'restablecimiento' en la máquina virtual y luego recupera los registros del sistema, puede cambiar el comportamiento. Asegúrese de que los registros sean del segundo arranque y no del primero; tienden a retrasarse en las actualizaciones.

Otra cosa que debe verificar es asegurarse de que la instancia responda en la IP. Parece que se está rechazando una conexión arriba, lo que parece que la instancia está activa, pero SSH no se está ejecutando o está cortafuegos, pero asegúrese de que la instancia se haya reiniciado por completo.

También puede intentar abrir todos los puertos desde un sistema de prueba y ver qué le muestra 'nmap': ¿hay algún otro servicio que responda en la instancia?

Haga clic derecho en el nombre de la instancia y haga clic en "Cambiar grupos de seguridad". Asegúrese de que el grupo de Seguridad que creó que permite a cualquier persona desde cualquier lugar hasta el Puerto 22 esté marcado y aplicado a esta instancia.

Tengo este problema después de hacerlo a sudo reboot nowtravés de SSH en mi servidor EC2 con Ubuntu 14.04. Funcionó bien después de reiniciar nuevamente usando la Consola de administración EC2.

En mi caso, configuré un grupo de seguridad para permitir conexiones de puerto 22 solo desde mi IP. Algunos días después, mi ISP ha cambiado mi dirección IP, por lo tanto, el grupo de seguridad necesita una actualización.

Tuve un problema similar, mi instancia EC2 Amazon Linux ya no era accesible después de ejecutar sudo reiniciar .

Sin acceso SSH, los comandos detener / iniciar / reiniciar desde la consola de administración de Amazon tampoco me dieron ningún resultado.

Finalmente pude reiniciar mi instancia creando una imagen a través de la consola de Amazon. El proceso de creación de imágenes parece corregir el estado de la instancia.

Espero eso ayude ;)

Tuve el mismo problema después de ejecutar un sudo rebootcomando de vainilla . Descubrí que podía resolver el problema deteniendo por completo (no reiniciando) mi AMI usando la consola de AWS y luego volviéndolo a iniciar.

Por alguna razón, reiniciar el AMI desde la consola de AWS, como hacer clic en la acción de reinicio en lugar de detener y luego iniciar la instancia, no solucionó el problema.

Como se mencionó, probablemente te metiste con / etc / fstab /

Tuve este problema Primero debe volver a agregar el volumen en / dev / sda1 como dice el mensaje de advertencia.

Entonces no pude ssh. Me di cuenta de que tenía que agregar el otro volumen que creé y eso solucionó el problema de ssh.

Luego puede iniciar sesión y volver a fijar el fstab al original.