☰

El servidor SSH no responde a la solicitud de conexión

tag-icon • tag-icon linux networking ssh firewall openssh
El servidor SSH no responde a la solicitud de conexión

Estoy intentando configurar un servidor SSH en mi máquina local usando OpenSSH. Cuando intento realizar SSH desde un host remoto a mi servidor SSH local, el servidor SSH no responde y la solicitud se agota. Estoy bastante seguro de que hay una solución realmente obvia para esto que simplemente estoy pasando por alto.

Esto es lo que sucede cuando intento iniciar sesión mediante SSH desde un host remoto:

yoshimi@robots:/$ ssh -vv [email protected]
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
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 99.3.26.94 [99.3.26.94] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: connect to address 99.3.26.94 port 22: Connection timed out
ssh: connect to host 99.3.26.94 port 22: Connection timed out

¿Dónde robotsestá mi host remoto y 99.3.26.94mi servidor SSH local?

SSH se está ejecutando

volt@arnold:~$ ps -A | grep sshd
 5784 ?        00:00:00 sshd

¿Dónde arnoldestá mi servidor SSH local?

El reenvío de puertos está configurado en el enrutador

Tengo el enrutador de mi casa configurado para reenviar los puertos 80 y 22 a mi servidor SSH. Curiosamente, el puerto 80 funcionó sin problemas: va directamente al directorio web de Apache. Puerto 22... no tanto.

NMap dice que está filtrado

yoshimi@robots:/$ nmap -p 22 99.3.26.94

Starting Nmap 6.47 ( http://nmap.org ) at 2015-06-02 14:45 EDT
Nmap scan report for 99-3-26-94.lightspeed.bcvloh.sbcglobal.net (99.3.26.94)
Host is up (0.33s latency).
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

¿Dónde robotsestá mi host remoto y 99.3.26.94mi servidor SSH local?

No son IPTables (creo)

volt@arnold:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-ssh (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere

...Y no tengo ningún otro firewall instalado: es un Debian netinst relativamente nuevo.

Por lo que entonces:¿Qué más podría ser?Ciertamente parece ser una especie de firewall para simplemente ignorar el tráfico, pero si no es el enrutador, no es iptables y no es otro firewall en el servidor SSH, ... ¿qué diablos más hay?

EDITAR: Salida del servidor NetStat

Desde el servidor SSH:

tcp6       0      0 :::22                   :::*                    LISTEN      5784/sshd

Respuesta1

Una autorespuesta muy decepcionante

Después de dejar este problema a un lado por un día y volver a él, me sentí aliviado y perturbado (más perturbado que aliviado) al descubrir que todo, misteriosamente, funcionaba correctamente.

Entonces, ¿cuál fue el problema?

No se cambió ni ajustó ninguna configuración, ni en el enrutador, ni en el servidor SSH, ni en la máquina del cliente SSH. Es bastante seguro decir que fue el enrutador el que no manejó el tráfico entrante correctamente, a pesar de tener la configuración adecuada. Dado que el pequeño software de enrutador doméstico no esen realidadDiseñado para lidiar con el reenvío de puertos, al pobre le tomó un tiempo implementar los cambios necesarios.

¡¡Pero han pasado como 6 horas!!

Sí amigo, lo sé. Pasé todo el día tratando de descubrir qué estaba mal y nunca lo encontré porqueno fuenada malo. Evidentemente, la configuración del enrutador puede tardar 6 horas (posiblemente más) en surtir efecto.

Entonces, ¿cómo sé si este es mi problema?

Una herramienta ingeniosa que encontré durante esta escapada es tcpdump. Este pequeño y delgado rastrea el tráfico por usted y le ofrece información valiosa sobre lo que realmente está sucediendo. Además, tiene algunas funciones de súper filtrado que te permiten limitar exactamente lo que quieres mirar o buscar. Por ejemplo, el comando:

tcpdump -i wlan1 port 22 -n -Q inout

Indica tcpdumpque busquemos tráfico a través de la interfaz wlan1 ( -i= 'interfaz'), solo a través del puerto 22, ignore la resolución de nombres DNS ( -n= 'sin resolución de nombres'), y queremos ver tanto el tráfico entrante como el saliente ( -Qacepta in, outo inout; inoutes el valor predeterminado).

Al ejecutar este comando en su servidor SSH mientras intenta conectarse a través de una máquina remota, rápidamente queda claro dónde radica exactamente el problema. Básicamente existen 3 posibilidades:

  1. si estas viendoentrantetráfico desde la máquina remota, perono salientetráfico de su servidor local, el problema radica en el servidor: probablemente haya una regla de firewall que deba cambiarse, etc.
  2. si estas viendotanto entrantes como salientes, pero su máquina remota no recibe la respuesta, lo más probable es que sea el enrutador: permite el tráfico entrante, pero descarta los paquetes salientes.
  3. Si hayno hay tráfico en absoluto, probablemente también sea un problema del enrutador: SYNel enrutador ignora y descarta los paquetes de la máquina remota incluso antes de que lleguen a su servidor.

Y una vez que haya descubierto dónde reside el problema, encontrar una solución (normalmente) es trivial.

información relacionada