Hoy decidimos que el mejor curso de acción para nuestro servidor Ubuntu (VPS) sería restaurar una copia de seguridad después de que se cambiaron demasiadas configuraciones en nuestra instancia de Geoserver. Sin embargo, después de restaurar la copia de seguridad y reiniciar, ya no puedo iniciar sesión en el servidor por medios normales a través de SSH. Simplemente me da un connection timed outerror.
Que he hecho:
- Usé el "Sistema de Rescate" para iniciar sesión en el Servidor a través de SSH (funcionó).
- Revisé el
sshd_configarchivoinit.d/sshen busca de cualquier cosa fuera de lo común. - Verifiqué el registro de autenticación para ver si siquiera notó mi intento de conexión SSH (lo cual no fue así).
Estoy completamente perplejo con este caso. Para mí, parece que la red no se activa en absoluto después de reiniciar. Sin embargo, no puedo conectarme directamente al servidor porque es un servidor privado virtual alojado de forma remota.
He buscado un poco en la web, pero nadie parece recibir el error "Se agotó el tiempo de conexión" que me está sucediendo en este momento.
El servidor se ejecuta en Ubuntu 14.04
¿Alguna sugerencia?
Nota adicional:
solo puedo conectarme al servidor cuando está en modo de emergencia, lo que significa que omite todo lo que hice en el servidor y lo coloca en un directorio /repair. Entonces, si yo, por ejemplo, compruebo qué puertos están abiertos, me dirá cuáles están abiertos desde el Modo de Emergencia, no desde mi propia instalación.
Información adicional de los comentarios:
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Respuesta1
verifique si el servidor puede hacer ping a su puerta de enlace predeterminada verifique si el ping funciona hacia el servidor desde afuera si el ping funciona, luego haga un tcpdump en la interfaz para verificar si la NIC en el servidor está recibiendo tráfico intente ssh desde el servidor -- ssh localhost #si esto no funciona - el propio sshd podría estar roto
Respuesta2
Compruebe si el servicio ssh se está ejecutando y si el puerto ssh está escuchando
netstat -ntap
Deberías ver una línea con el puerto 22 escuchando el proceso sshd:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN pid number/sshd
Si el proceso está activo y escuchando, verifique la configuración de red; si no está activo, verifique si sshd está instalado y ejecutándose
Respuesta3
Primero: gracias a todos por su ayuda con respecto a este problema.
Segundo: debido a las circunstancias, ya no pudimos esperar y decidimos recargar una copia de seguridad diferente, que pareció funcionar. No pudimos determinar qué causó exactamente el error debido a que la nueva copia de seguridad que funcionó no tenía ninguna diferencia con la que falló y, por lo tanto, consideramos que se trata de un problema de copia de seguridad defectuosa.
Gracias de nuevo por la ayuda, realmente apreciada.
Respuesta4
Podría intentar hacer un nmap del servidor para ver qué puertos están abiertos en la red. Deberías ver el puerto 22 abierto.