¿Tiempo de espera de conexión para el servidor Ssh?

Estoy tratando de configurar el servidor openssh, pero tengo algunos problemas para conectarme. Cambié el puerto a algo no estándar (57757) y luego configuré mi enrutador para reenviar a ese puerto. En mi LAN, puedo ingresar a mi máquina sin problemas usando el puerto 57757, pero no puedo hacerlo en la WAN.

Si estoy fuera de la LAN e intento acceder a mi máquina a través de un puerto incorrecto, recibo inmediatamente un mensaje de "conexión rechazada". Sin embargo, con el puerto correcto simplemente se bloquea y luego se agota el tiempo de espera.

¿Qué puedo intentar para depurar el problema? Probé un traceroute, pero no me dijo nada útil.

EDITAR:Me di cuenta de que mi problema era que mi enrutador no admitía el acceso a través de IP WAN internamente. Salí a un servidor diferente y volví a entrar y funcionó bien.

Respuesta aceptada:

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.

De forma predeterminada, 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, hará lo siguiente:

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

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

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

Cuando reenvías un puerto a un inexistente máquina con un enrutador NAT, envía el tráfico entrante en ese puerto a la máquina inexistente, lo que quiere decir que lo envía a un agujero negro; se cae 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 reenvía a la dirección IP correcta en la LAN.

Si resulta que ese no ha sido el problema...

…entonces tendrás que solucionar algunos problemas.

1. ¿Es correcto el puerto especificado para el lado LAN? Es decir, suponiendo que no haya cambiado la configuración del servidor SSH, el puerto 57757 en el lado WAN está configurado para reenviar al puerto 22 en el servidor OpenSSH? (Es posible que desee volver a verificar esto).

2. Quizás haya algún problema con el puerto específico que has elegido (57757). Pruebe con uno diferente y vea si funciona mejor.

   (Si no es así, y continúa con estas instrucciones, vuelva a cambiarlo o reemplace "57757" a continuación con el nuevo número).

3. 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 por cable/DSL/ISDN también.

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

   Para reiniciar el servidor OpenSSH:

   sudo restart ssh
   

   Para desactivar la interfaz de red, primero averigüe en qué interfaz está:

   ifconfig
   

   Por lo general, para una máquina con una sola tarjeta Ethernet y/o una sola tarjeta inalámbrica, la Ethernet es eth0 y la conexión inalámbrica es wlan0 .

   Si lo que desea desconectar y reiniciar es la conexión Ethernet por cable, ejecute:

   sudo ifdown eth0
   

   Luego ejecuta:

   sudo ifup eth0
   

   Alternativamente, puede ejecutar:

   sudo ifconfig eth0 down
   

   Seguido por:

   sudo ifconfig eth0 up
   

   Si la máquina usa NetworkManager para administrar la interfaz en la que se ejecuta el servidor OpenSSH, aún 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 desenchufar el cable y volver a enchufarlo. Para una conexión inalámbrica, intente apagarlo con el interruptor de hardware (si lo hay) y vuelva a encenderlo.

   Algo extraño está sucediendo aquí y nada de esto toma mucho tiempo; vale la pena ser minucioso antes de emprender pasos de solución de problemas más minuciosos.

4. ¿Cómo intenta acceder desde el lado WAN? Si está utilizando una máquina en la LAN para hacer esto (simplemente 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 y no la regla, aunque muchos enrutadores domésticos/de oficina tienen esta función.

   Entonces, si no está probando el reenvío del puerto 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á conectado a él, 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 estos días, 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 IP WAN y máscara de subred WAN, luego asigne estáticamente una dirección IP a la máquina conectada al 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 incorrectamente para que la máquina de prueba conectada al conmutador pueda acceder a Internet. (A menos que la intención de su ISP sea permitirle conectarse con más de una IP WAN y Si ha elegido una IP WAN para la máquina de prueba que su ISP le ha asignado, el ISP debe bloquear/desconectar el tráfico entre esta y un verdadero host WAN. Pero algunos ISP tienen prácticas extrañas, entonces, ¿quién sabe?) Si esto sucede, es probable que no cause problemas serios a nadie (e incluso si lo hiciera, solo lo tiene conectado por unos minutos). Sin embargo, podría verse potencialmente 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 inmediatamente si encuentra que la máquina de prueba puede acceder a Internet y no intente hacerlo 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 a su administrador de red. Eso no es un ISP y no se asume que los recursos se aprovisionan para evitar accesos no deseados).

     Hay una variación de esta técnica que a veces es más apropiada. Es probable que su enrutador obtenga su información de conexión:dirección IP, máscara de subred, la dirección IP de la puerta de enlace (enrutador) en la WAN que eso se usa cuando no sabe a dónde enviar algo e información sobre servidores DNS, desde su ISP, a través de DHCP, a través del módem de cable/DSL/ISDN. Esta es la razón por la que debe tener el enrutador conectado al módem para darle la configuración necesaria para que los resultados de las pruebas del lado WAN sean significativos. Pero el enrutador normalmente 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 y antes de hacer nada con la máquina de prueba, además de asegurarse de que el interruptor lo vea como conectado , desconecte el módem.

   • Utilice un servicio gratuito en Internet para probar sus puertos. Dado que insertar una máquina de prueba entre la interfaz WAN de su enrutador e Internet (arriba) es muy complicado, y dado que mostrará un puerto como accesible incluso si es inaccesible debido a que su ISP lo bloqueó (lo cual también es cierto para conectarse al puerto del enrutador). WAN IP desde el lado de la LAN):por lo general, es mejor usar un servicio de escaneo de puertos basado en la web.

     Hay muchos servicios de escaneo de puertos. (Algunos usan la frase "verifique su firewall" con la idea de que la mayoría de las personas están tratando de bloquear en lugar de facilitar acceso.) Este es uno. Si elige usar ese, haga clic en Continuar , escriba 57757 en el cuadro de texto y haga clic en Usar sonda de puerto personalizado especificado . Con el fin de hacer que un servidor funcione, usted quiere que sea "abierto". "Cerrado" significa que se puede acceder al puerto pero el servidor no se está ejecutando (y, por lo tanto, se rechazó el intento de conexión). "Sigiloso" significa que el puerto era inaccesible; es como si no hubiera ninguna máquina ubicada allí (o como si el puerto se reenviara donde no hay ninguna máquina).

5. Bien, entonces ha 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 brindará información útil.

   Si desea hacer esto, en el lado 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 vayan a ninguna parte (o se bloqueen o se descarten en el camino).

6. Vale la pena verificar si el problema se debe a que el puerto expuesto a la WAN es diferente del puerto en el que el servidor realmente está escuchando. Reenviar el puerto 55757 en la WAN al puerto 22 en la máquina LAN debería hacer que las cosas funcionen bien, pero tal vez en algún lugar (el servidor, el cliente) algo suponga 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 bloquee ese puerto. Pero si puedes hacer eso, ¡hazlo!

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

   Para ello, haga una copia de seguridad del archivo de configuración del servidor:

   cd /etc/ssh
   sudo cp sshd_config sshd_config.old
   

   Luego edítalo:

   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
   

   Solo cambia el Port 22 línea en la parte superior, para decir Port 57757 en su lugar.

   • Podrías añadir un puerto en lugar de cambiarlo. Sin embargo, recomiendo probar con la configuración efectiva más simple.

     Ver man sshd_config para 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 reenvío de puerto en el enrutador para que el puerto 57757 reenvíe al puerto 57757 (no al 22) en el servidor OpenSSH y vea si es accesible desde Internet.

7. Si sigue sin funcionar, compruebe si el cortafuegos de Ubuntu 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 reveló nada sobre el problema, vale la pena verificarlo).

   Ejecutar:

   sudo iptables -L
   

   De forma predeterminada, 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 firewall de netfilter no estuviera compilado en su kernel, su sistema se comportaría de la misma manera que con la configuración anterior, aunque las iptables comando, que consulta netfilter la configuración, no funcionaría, por supuesto.)

   Si su configuración no se ve así, lea man iptables para averiguar qué están haciendo y/o edite su pregunta (o, si es otra persona con un problema similar al leer esto, publique una nueva pregunta) para incluirlos. Tenga en cuenta que, potencialmente, sus iptables Las reglas 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 reglas sobre hosts específicos que están bloqueados, o si su configuración es muy mala o insegura, por lo general, 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ínimo.

Relacionado:NVidia GeForce GTX970 problema ubuntu 16.04?