El servidor SSH no responde a las solicitudes de conexión

Estoy intentando configurar un servidor SSH en mi máquina local usando OpenSSH. Cuando trato de SSH desde un host remoto a mi servidor SSH local, el servidor SSH no responde y la solicitud agota el tiempo de espera. 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 ingresar a SSH desde un host remoto:

yoshimi@robots:/$ ssh -vv volt@99.3.26.94
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 mi enrutador casero 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 cortafuegos en su lugar: es un netinst de Debian relativamente nuevo.

Entonces, entonces: ¿Qué más podría ser? Ciertamente parece ser un tipo de cortafuegos simplemente ignorar el tráfico, pero si no es el enrutador, no es iptables, y no es otro cortafuegos en el servidor SSH ... ¿qué demonios hay?

EDITAR: solicitud de conexión de error de red interna

yoshimi@robots:/$ ssh volt@192.168.1.90
ssh: connect to host 192.168.1.90 port 22: No route to host

Una auto respuesta muy decepcionante

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

Entonces, ¿cuál fue el problema?

No se cambiaron ni se ajustaron configuraciones, 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 la configuración adecuada. Dado que el software de enrutador doméstico de mala calidad no es realmente diseñ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é porque no había nada malo. Evidentemente, puede tomar 6 horas, posiblemente más, para que la configuración del enrutador surta efecto.

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

Una herramienta ingeniosa que encontré durante esta aventura es tcpdump. Este pequeño y esbelto olfatea tráfico para ti, ofreciéndote información valiosa sobre lo que realmente está sucediendo. Además, tiene algunas características de superfiltrado que le permiten reducir exactamente lo que desea ver / para. Por ejemplo, el comando:

tcpdump -i wlan1 port 22 -n -Q inout

Dice tcpdumpque mirar para el tráfico a través de la interfaz wlan1 ( -i'Interfaz' =), sólo a través del puerto 22, ignorar la resolución de DNS nombre ( -n= 'sin resolución de nombres'), y que queremos ver tanto el tráfico entrante y saliente ( -Qacepta in, outo inout;inout es el 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 precisamente el problema. Hay, esencialmente, 3 posibilidades:

1. Si ve tráfico entrante desde la máquina remota, pero no sale tráfico desde su servidor local, el problema radica en el servidor: probablemente haya una regla de firewall que deba cambiarse, etc.
2. Si está viendo tanto entrantes como salientes , pero su máquina remota no recibe la respuesta, lo más probable es que sea el enrutador: está permitiendo el tráfico entrante, pero descartando sus paquetes salientes.
3. Si no 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 antes de que lleguen al servidor.

Y una vez que haya descubierto dónde radica el problema, una solución es (generalmente) trivial.

Estoy ejecutando Mint (Ubuntu).

Había hecho todo ... clave pública en formato correcto en claves autorizadas, chmodding, chowning, reinicio de ssh y sshd, etc. Como se ha documentado en todo el lugar.

Para mí, fue el firewall ufw. La falta de una respuesta ssh me señaló esto, pero no pude hacer ping en ambas direcciones en una LAN.

Probé por:

sudo ufw service stop

... y funcionó perfectamente, es decir, recibí una respuesta de una llamada ssh.

Entonces, comience de nuevo:

sudo ufw service start

... y agrega la regla:

sudo ufw allow openssh

Todo funciona bien ahora.

Si, como yo, ha habilitado UFW (en Linux, Ubuntu en mi caso), intente esto:

sudo ufw enable OpenSSH

Esto permitirá OpenSSH en el firewall.

Solo para otros:

Tuve que usar la opción -P en tcpdump en lugar de -Q

tcpdump -i wlan1 port 22 -n -P inout

La mayoría de las veces el firewall es un culpable. Hacer service iptables stopy service ip6tables stop.

Si detener el servicio no funciona, entonces haga iptable flush.

iptables --flush.

Si es una máquina virtual, haga lo mismo en el host también