¿Qué causa los problemas de SSH después de reiniciar un servidor 14.04?

¿Por qué reiniciar un servidor que ejecuta Ubuntu 14.04 me da errores de 'Conexión rechazada'?

Lo veo ssh: connect to host <IP-address-here> port 22: Connection refusedpero solo para 14.04 y solo después de reiniciar. Estoy usando 12.04 Desktop en casa. ¿Cómo soluciono esto?

Para aclarar la pregunta, esto es lo que funciona o no para mí:

• SSH en una nueva instalación de 12.04> cerrar sesión> SSH nuevamente> funciona
• SSH en una nueva instalación de 12.04> reiniciar> SSH de nuevo> funciona
• SSH en una nueva instalación de 14.04> cerrar sesión> SSH nuevamente> funciona
• SSH en una nueva instalación de 14.04> reiniciar> SSH de nuevo> Conexión rechazada

El problema que tengo es exclusivo de 14.04, y solo ocurre después de reiniciar. Tengo varios servidores ejecutando 12.04 antes de esto y todo sigue funcionando perfectamente. Tengo un nuevo servidor en el que quiero usar 14.04 y quiero entender qué está mal. ¿Alguna sugerencia?

Esto es lo que he probado hasta ahora:

sudo traceroute -p 22 -T <IP-address-here>

Traceroute funciona bien, recibo una respuesta del servidor en el puerto SSH 22.

initctl list
...
ssh start/running, process 23371
...

Parece que ssh en el servidor 14.04 está configurado para comenzar en el arranque (como se esperaba).

tom@Desktop:~$ ssh -vvv root@<IP-address-here>
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to <IP-address-here> [<IP-address-here>] port 22.
debug1: connect to address <IP-address-here> port 22: Connection refused
ssh: connect to host <IP-address-here> port 22: Connection refused

Editar: Aquí está todo el syslog de una máquina recién creada . Lo creé, ingresé SSH y emití un reboot nowcomando, luego recibí un error de conexión rechazada después de esperar a que se reiniciara e intenté SSH por segunda vez. Reinicio completo a través del panel de control de alojamiento y ahora la conexión SSH funciona nuevamente.

Respuesta rápida:

SSH no es el problema. El comando que usa para reiniciar es el problema: no hacer reboot now, hacer rebooto shutdown -r nowreiniciar su sistema.

La sintaxis del comando ( desde 13.04 ) ha sido:

reboot [OPTION]...  [REBOOTCOMMAND]

El REBOOTCOMMANDnunca existió antes. En 12.04, nowsimplemente fue ignorado pero ahora se está utilizando ... Y está rompiendo todo.

Respuesta larga, con mis resultados de pruebas y explicación:

Tengo un problema similar con algunos servidores que ejecutan 14.04 AND en VPS (alojado en el proveedor francés OVH - que ejecuta OpenVZ) Y cuando lo hago reboot nowdentro del servidor.

Como usted, he emitido el comando reboot nowdesde la consola (conectado con SSH). Unos segundos después de presionar RETURN, mi sesión se desconecta automáticamente. Como usted, nunca he podido volver a conectarme al servidor a través de SSH después de emitir este comando.

Entonces, decidí abrir la consola KVM proporcionada por OVH. (emulando el acceso directo usando el teclado y la pantalla en un servidor físico para este tipo de servidor virtual).

Pude conectarme a mi máquina y vi que estaba entrando en modo de usuario único, esperando que presione CTRL+ Dpara continuar o que ingrese la contraseña de root para entrar en modo de mantenimiento. Presioné la combinación de teclas para dejar que el proceso continuara y luego pude SSH en mi sistema nuevamente. ¿Cuál fue mi sorpresa al ver, después de la ejecución uptime, que el tiempo de actividad no fue de 2 o 3 minutos, pero aún así fue mucho día: reboot nowejecutado dentro de un Ubuntu 14.04 VPS no se reinicia realmente, sino que solo pide ingresar al modo de usuario único!

De esto, aprendí a nunca pedir un reinicio desde mi VPS, sino a solicitarlo desde el comando proporcionado en la interfaz de administración del host.

Por lo tanto, no hay problema con su instalación SSH. El problema es cuando escribes reboot now. De hecho, también lo probé después, si hubiera escrito reboot(solo la palabra, sin opción), habría hecho lo que tenía intención de hacer: reiniciar el servidor.

Usando rebootcon un argumento (desde la página del manual) llame al comando shutdowncon los argumentos dados. Y, de hecho, si ejecuto shutdown now, tengo el mismo comportamiento: el sistema no se reinicia, entra en modo de usuario único.

Observación: parece que es el comportamiento previsto ya que el mensaje que aparece en la pantalla después de presionar al ejecutar este comando dice algo como:

El sistema pasará al modo de mantenimiento.

Modo de mantenimiento o modo de usuario único, esto representa lo mismo, un nivel de ejecución con más de un shell, sin red, sin procesos de red, ...

Esto puede ser confuso, pero tenga en cuenta que el uso correcto de shutdownes, por ejemplo: shutdown -h nowdetener el sistema ahora o shutdown -r nowreiniciarlo ahora. No sabía que eso shutdown nowsolo llevaría el sistema al modo de usuario único. Usualmente lo hago init Spara lograr esto.

Puedo llegar tarde, y puede ser obvio, pero lo que funcionó para mí fue verificar el archivo de configuración /etc/ssh/sshd_config: ejecutar el daemon con /etc/init.d/ssh starto cualquier otra combinación mostró que el servicio se estaba ejecutando aunque no lo estaba, pero si inicio el ejecutable con su ruta absoluta (en mi caso /usr/sbin/sshd) vi que había un "0B" al final del archivo de configuración que causó un error al iniciar, eliminarlo resolvió el problema.

Otra posible causa es ufwperder la configuración de la regla de puerto SSH. Esto se me ocurrió al menos en una o dos ocasiones, donde después de aplicar actualizaciones y reiniciar, la configuración del firewall me estaba bloqueando y obtuve acceso al servidor. El uso de la consola VPS de mi proveedor de hosting me permitió ingresar a la máquina y diagnosticar el problema. El siguiente ejemplo muestra el problema (es decir, no hay entrada para el puerto 22):

user@host:~$ sudo ufw status verbose
[sudo] password for user:
Status: active
Logging: on (low)
    Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
80,443/tcp (Nginx Full)    ALLOW IN    Anywhere
25/tcp                     ALLOW IN    Anywhere
143                        ALLOW IN    Anywhere
110                        ALLOW IN    Anywhere
993/tcp (Dovecot Secure IMAP) ALLOW IN    Anywhere
995/tcp (Dovecot Secure POP3) ALLOW IN    Anywhere
25/tcp (Postfix)           ALLOW IN    Anywhere
465/tcp (Postfix SMTPS)    ALLOW IN    Anywhere
80,443/tcp (Nginx Full (v6)) ALLOW IN    Anywhere (v6)
25/tcp (v6)                ALLOW IN    Anywhere (v6)
143 (v6)                   ALLOW IN    Anywhere (v6)
110 (v6)                   ALLOW IN    Anywhere (v6)
993/tcp (Dovecot Secure IMAP (v6)) ALLOW IN    Anywhere (v6)
995/tcp (Dovecot Secure POP3 (v6)) ALLOW IN    Anywhere (v6)
25/tcp (Postfix (v6))      ALLOW IN    Anywhere (v6)
465/tcp (Postfix SMTPS (v6)) ALLOW IN    Anywhere (v6)

Volver a habilitar el puerto de la siguiente manera hace el truco:

user@host:~$ sudo ufw allow ssh
Rule added
Rule added (v6)

Para mi sistema, el problema era que el script de inicio ssh /etc/init.d/sshera el único que verificaba la presencia de la versión inicial de init.

Entonces /etc/init.d/sshno comienza ssh,porque cree que será iniciado por upstart.

En mi caso, el arranque no se inicia debido a mi configuración particular:

Había una configuración correcta /etc/init/ssh.conf, pero también había un /etc/init/ssh.overridearchivo que contenía manual, lo que significa que sshse espera que se inicie manualmente.

Este archivo fue creado por el get-remnux.shscript de instalación.

Comenzar manualmente o eliminar el /etc/init/ssh.overridearchivo resuelve el problema.