Tiempo de espera de conexión para el servidor ssh

Por lo general, esto significa que ha reenviado el puerto a la dirección IP incorrecta en la LAN.

Su enrutador NAT recibe tráfico entrante en el puerto 57757 y lo envía a una dirección IP y puerto en particular en la LAN.

Por defecto, Ubuntu no filtra los intentos de conexión entrantes con un firewall. Entonces, a menos que haya cambiado la configuración del firewall en Ubuntu, un intento de abrir una conexión a cualquier puerto TCP, del 1 al 65535, bien:

aceptar la conexión, si el puerto está abierto
rechazar el intento de conexión, si el puerto está cerrado

Si los puertos fueron filtrados por un firewall, obtendría lo que está viendo, sin respuesta a un intento de conexión. Pero:

a menos que haya cambiado la configuración del firewall (p. ej. ufw, iptables), no se filtran los puertos y
en cualquier caso, puede conectarse al puerto 22 en la LAN, por lo que está abierto.

Cuando reenvía un puerto a una máquina inexistente con un enrutador NAT, envía el tráfico entrante en ese puerto a la máquina inexistente, lo que significa que lo envía a un agujero negro ; se deja caer efectivamente.

Eso causa exactamente la situación que has descrito. Por lo tanto, lo más probable es que pueda solucionar esto asegurándose de que el puerto se envíe a la dirección IP correcta en la LAN.

Si eso resulta no haber sido el problema ...

... entonces tendrás que hacer alguna solución de problemas.

¿El puerto especificado para el lado LAN es correcto? Es decir, suponiendo que no haya cambiado la configuración del servidor SSH, ¿está configurado el puerto 57757 en el lado WAN para reenviar al puerto 22 en el servidor OpenSSH? (Es posible que desee verificar esto dos veces).
Tal vez haya algún problema con el puerto específico que haya elegido (57757). Pruebe con uno diferente y vea si eso funciona mejor.

(Si no es así, y continúa con estas instrucciones, cámbielo o reemplace "57757" a continuación con el nuevo número).
Intente reiniciar el servidor OpenSSH. Eso puede ayudar si hay un problema de red. Si eso no ayuda, intente reiniciar el enrutador y el módem de cable / DSL / ISDN también.

Si por alguna razón no puede reiniciar los tres dispositivos, le recomiendo reiniciar lo que pueda. Si no puede reiniciar el servicio OpenSSH, al menos puede reiniciar el servicio y (lo más probable es que solucione esto) baje la interfaz y vuelva a abrirla.

Para reiniciar el servidor OpenSSH:
```
sudo restart ssh
```
Para desactivar la interfaz de red, primero descubra en qué interfaz está:
```
ifconfig
```
Típicamente, para una máquina con una sola tarjeta Ethernet y / o una sola tarjeta inalámbrica, Ethernet es eth0y la inalámbrica es wlan0.

Si la conexión Ethernet por cable es lo que desea quitar y reiniciar, ejecute:
```
sudo ifdown eth0
```
Entonces corre:
```
sudo ifup eth0
```
Alternativamente, puede ejecutar:
```
sudo ifconfig eth0 down
```
Seguido por:
```
sudo ifconfig eth0 up
```
Si la máquina está utilizando NetworkManager para administrar la interfaz en la que se ejecuta el servidor OpenSSH, todavía recomiendo probar las formas anteriores, pero también puede intentar desconectarse y volver a conectarse en NetworkManager.

Para una conexión Ethernet, también intente desconectar el cable y volver a enchufarlo. Para una conexión inalámbrica, intente apagarlo con el interruptor de hardware (si hay uno) y vuelva a encenderlo.

Algo extraño está sucediendo aquí y nada de esto lleva mucho tiempo: vale la pena ser exhaustivo antes de emprender más pasos de resolución de problemas.
¿Cómo intenta acceder desde la WAN? Si está utilizando una máquina en la LAN para hacer esto (solo conectándose desde la LAN a la IP WAN de su enrutador), esto solo es compatible con algunos enrutadores. Después de todo, el trabajo de un enrutador es enrutar el tráfico entre los lados WAN y LAN, no enrutar el tráfico de un lado a sí mismo. El soporte para conectarse a puertos reenviados en la IP WAN desde dentro de la LAN es en realidad la excepción más que la regla, aunque muchos enrutadores domésticos / de oficina tienen esta característica.

Entonces, si no está probando el puerto hacia adelante desde un host en el lado WAN, debe hacerlo. Sus opciones para esto son:
- Conéctese desde el lado WAN. Esto funciona si tiene acceso a una máquina allí, por ejemplo, acceso SSH a una máquina remota en la escuela, el trabajo, la casa de un amigo o similar.
- Conecte la máquina de prueba entre el enrutador y lo que sea que proporcione su conexión a Internet. Si tiene un módem de cable / DSL / ISDN con un puerto Ethernet y su enrutador está enchufado, puede conectar un conmutador al módem y conectar el enrutador al conmutador. Conecte una computadora al interruptor. Primero vea si esa máquina solo tiene acceso a Internet; en la actualidad, muchos ISP proporcionan dos o más direcciones IP separadas. Si no es así , vaya a la página de configuración de su enrutador y verifique su máscara de subred WAN IP y WAN , luego asigne estáticamente una dirección IP a la máquina conectada por conmutador que se encuentra dentro de la misma subred.
  
  Este método tiene algunas desventajas. ¡Es un dolor! Además, teóricamente es posible que un ISP configure su red de manera incorrecta para que la máquina de prueba conectada al conmutador pueda acceder a Internet. (A menos que sea la intención de su ISP permitirle conectarse con más de una IP WAN ysi ha elegido una IP WAN para la máquina de prueba que le ha asignado su ISP, el ISP debe bloquear / descartar el tráfico entre él y un verdadero host WAN. Pero algunos ISP tienen prácticas extrañas, ¿quién sabe?) Si esto sucede, es probable que no cause problemas serios a nadie (e incluso si lo hiciera, solo lo tiene conectado durante unos minutos). Sin embargo, podría verse como un intento de obtener acceso adicional más allá de los límites de su suscripción y, lo que es más importante, si otro usuario tiene la misma IP, podría interferir con su conexión. Por lo tanto, si quieres probar este método, no intente acceder a Internet desde la máquina de prueba, deténgase de inmediato si encuentra que la máquina de prueba puede acceder a Internet, y no intente esto en absoluto si su ISP lo prohíbe o desaconseja. (Y no use esto si el lado WAN de su enrutador es una LAN de oficina, sin consultar primero con su administrador de red. Eso no es un ISP y no se supone que los recursos estén aprovisionados para evitar el acceso no deseado).
  
  Hay una variación en esta técnica que a veces es más apropiada. El router probablemente obtiene su información de conexión - dirección IP, máscara de subred, la dirección IP de la pasarela (router) de la WAN que se utiliza cuando no se sabe a dónde enviar algo, y la información acerca de los servidores DNS - desde su ISP, a través de DHCP, a través del módem de cable / DSL / ISDN. Es por eso que debe tener el enrutador conectado al módem para darle la configuración necesaria para que los resultados de las pruebas en el lado de la WAN sean significativos. Pero el enrutador generalmente recordará esta información, siempre que esté realmente conectado a una red en el lado WAN. Entonces puede conectar el enrutador, el módem y la máquina de prueba, pero luego, rápidamente, yantes de hacer algo con la máquina de prueba además de asegurarse de que el interruptor lo vea como conectado , desconecte el módem.
- Use un servicio gratuito en Internet para probar sus puertos. Dado que la inserción de una máquina de prueba entre la interfaz WAN de su enrutador e Internet (arriba) es muy complicada, y ya que mostrará un puerto accesible incluso si es inaccesible debido a que está bloqueado por su ISP (que también es cierto al conectarse a la IP WAN del enrutador desde el lado LAN): generalmente es mejor usar un servicio de escaneo de puertos basado en la web.
  
  Hay muchos servicios de escaneo de puertos. (Algunos tienen la frase "revise su firewall" con la idea de que la mayoría de las personas están tratando de bloquear en lugar de facilitar el acceso). Esta es una. Si elige usarlo, haga clic en Continuar , escriba 57757 en el cuadro de texto y haga clic en Usar sonda de puerto personalizada especificada . Con el fin de ejecutar un servidor, desea que esté "abierto". "Cerrado" significa que se puede acceder al puerto pero que el servidor no se está ejecutando (y, por lo tanto, se rechazó el intento de conexión). "Sigilo" significa que el puerto era inaccesible, es como si no hubiera una máquina ubicada allí (o como si el puerto fuera reenviado donde no hay máquina).
OK, entonces has determinado que realmente no es accesible desde Internet. Potencialmente, puede escanearlo (idealmente desde el lado de la WAN) para obtener detalles, aunque a menudo esto no proporcionará información útil.

Si desea hacer esto, en el lado de la WAN, puede ejecutar:
```
sudo nmap -sS -sV -p57757 -vv WAN-IP
```
Si el puerto se muestra como filtrado, eso confirma que los paquetes enviados allí probablemente no irán a ninguna parte (o están bloqueados / descartados en el camino).
Vale la pena verificar si el problema está surgiendo porque el puerto expuesto a la WAN es diferente del puerto en el que el servidor realmente está escuchando. El reenvío del puerto 55757 en la WAN al puerto 22 en la máquina LAN debería hacer que las cosas funcionen bien, pero quizás en algún lugar (el servidor, el cliente) algo está asumiendo que el número de puerto es el mismo desde la perspectiva del servidor y del cliente.

Presumiblemente no puede reenviar el puerto 22 a través del enrutador. Quizás su ISP bloquea ese puerto. Pero si puedes hacer eso, ¡haz eso!

De lo contrario, puede hacer que el servidor OpenSSH realmente escuche en el puerto 57757.

Para hacer esto, haga una copia de seguridad del archivo de configuración del servidor:
```
cd /etc/ssh
sudo cp sshd_config sshd_config.old
```
Luego edítelo:
```
gksu gedit sshd_config
```
O use un editor de texto de consola si la máquina no tiene una GUI:
```
sudo nano -w sshd_config
```
Cerca de la parte superior del archivo, aparece este bloque de texto:
```
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
```
Simplemente cambie la Port 22línea en la parte superior, para decir en su Port 57757lugar.
- Puede agregar un puerto en lugar de cambiarlo. Sin embargo, recomiendo probar con la configuración efectiva más simple.
  
  Consulte man sshd_configpara obtener más detalles sobre la configuración del servidor OpenSSH.
Guarde el archivo, salga del editor de texto y reinicie el servidor SSH con:
```
sudo restart ssh
```
Ahora cambie el puerto hacia adelante en el enrutador para que el puerto 57757 reenvíe al puerto 57757 (no 22) en el servidor OpenSSH, y vea si es accesible desde Internet.
Si todavía no funciona, vea si tal vez el firewall de Ubuntu en realidad está bloqueando el tráfico que se origina fuera de la LAN.

(Esto es poco probable si no lo configuró de esta manera usted mismo, pero si todas sus configuraciones son correctas y ninguno de los pasos anteriores revelaron nada sobre el problema, vale la pena verificarlo).

Correr:
```
sudo iptables -L
```
Por defecto, en Ubuntu, la salida se ve así:
```
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
```
Esta es una política permisiva simple, esencialmente equivalente a no ejecutar un firewall. (De hecho, si el módulo de cortafuegos netfilter no se compilara en su núcleo, su sistema se comportaría de la misma manera que con la configuración anterior, aunque el iptablescomando, que consulta netfilterla configuración, no funcionaría, por supuesto).

Si su configuración no se ve así, lea man iptablespara averiguar qué están haciendo y / o edite su pregunta (o, si es una persona diferente con un problema similar al leer esto, publique una nueva pregunta) para incluir ellos. Tenga en cuenta que, potencialmente, sus iptablesreglas podrían revelar información confidencial sobre su configuración. En términos prácticos, este no suele ser el caso, con la posible excepción de las reglas sobre hosts específicos que están bloqueados, o si su configuración es muy mala / insegura, generalmente la utilidad de esta información para un atacante, especialmente para una máquina en una LAN doméstica / de oficina detrás de un enrutador NAT es mínima.

Eliah Kagan
fuente

Tiempo de espera de conexión para el servidor ssh

Respuestas:

Si eso resulta no haber sido el problema ...