El 17 de mayo de 2021 19:49:11 CEST, Walter Omar Dari <wlin...@gmail.com> escribió: > > >El 17/5/21 a las 13:12, Camaleón escribió: >> El 2021-05-17 a las 12:37 -0300, Walter Omar Dari escribió: >> >>> El 16/5/21 a las 03:52, Camaleón escribió: >>>>>>> debug2: ssh_connect_direct >>>>>>> debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22. >>>>>>> >>>>>>> ... después de un rato da un error de timeout. >>>>>> >>>>>> Un error de timeout apunta a que el anfitrión (el equipo al que >>>>>> conectas) corta la conexión por algún motivo (directiva de >seguridad, >>>>>> etc.); si llegas con un ping al equipo, así a bote pronto el >cortafuegos >>>>>> quedaría descartado. >>>>> >>>>> El ping me responde inmediatamente... >>>>> >>>>> $ ping 192.168.0.8 >>>>> PING 192.168.0.8 (192.168.0.8) 56(84) bytes of data. >>>>> 64 bytes from 192.168.0.8: icmp_seq=1 ttl=64 time=0.344 ms >>>>> 64 bytes from 192.168.0.8: icmp_seq=2 ttl=64 time=0.330 ms >>>>> 64 bytes from 192.168.0.8: icmp_seq=3 ttl=64 time=0.338 ms >>>>> 64 bytes from 192.168.0.8: icmp_seq=4 ttl=64 time=0.331 ms >>>>> ^C >>>> >>>> Hum... prueba con una traza, aunque me temo que no proporcionará >mucha más >>>> información: >>>> >>>> traceroute -T -O info -p 22 192.168.0.8 >>> >>> Te detallo algunas otras cosas que hice (sugerencias de Zeque), al >final >>> está la traza... >>> >>> /home/sw/Uso_compartido/temp/ssh_noconecta2.txt [BM--] 9 L:[ >1+26 27/ >>> 56] *(775 /1070b) 0010 0x00A [*][X] >>> 1) en el equipo que no permite las conexiones (192.168.0.8)... >>> >>> root@debbns:~# iptables -L >>> bash: iptables: orden no encontrada >>> >>> root@debbns:~# dpkg -l | grep iptables >>> ii iptables 1.8.7-1 amd64 administration tools for >packet >>> filtering and NAT >> >> ? >> >> Prueba con: >> #su - -c "iptables -L" >> >>> hosts.allow y hosts.deny están vacíos (salvo las lìneas comentadas >al >>> principio), no hay direcciones IP ni nombres de hosts. >>> >>> Probé agregando la línea... >>> >>> ALL : ALL : allow >>> >>> ... en hosts.allow, pero tampoco da resultados. >>> >>> >>> 2) en cualquier equipo que se quiera conectar a 192.168.0.8... >>> >>> dari@debwal:~$ nc -vvv 192.168.0.8 22 >>> ^C sent 0, rcvd 0 >>> >>> root@debwal:/home/dari# traceroute -T -O info -p 22 192.168.0.8 >>> traceroute to 192.168.0.8 (192.168.0.8), 30 hops max, 60 byte >packets >>> 1 * * * >>> 2 * * * >> >> (...) >> >> No llega. >> >>>> Si la conexión fuera entre redes distintas (remotas), pasando el >>>> tráfico por distintos servidores y enrutadores que no están bajo tu >>>> supervisión, podría entenderse el timeout por algún filtro de los >ISP, >>>> el tamaño de los paquetes o cortafuegos, pero teniendo controlado >el >>>> entorno de conexión (red local) el tiemout es todo un misterio :-? >>>> >>>> Si tienes otro equipo desde donde probar (p. j., otro sistema >operativo >>>> como Windows con Putty o MacOS), intenta a ver, no vaya a ser que >la >>>> guerra te la esté dando el cliente desde donde conectas. >>> >>> He probado desde otros equipos con Debian y el resultado es el >mismo. >>> El tema tiene que estar en el huraño 192.168.0.8 :-) >>> >>> A ese equipo lo actualicé, no fue una instalación desde cero, >anteriormente >>> tenía Buster, así que le modifiqué el sources.list reemplazando >buster por >>> bullseye. La actualización no dio problemas. >>> >>> Voy a ver si encuentro alguna portátil a la que le haya quedado un >dual boot >>> con Windows para probar con Putty >>> >>> Gracias ! >> >> Sólo por curiosidad... ¿has probado a intentar conectarte a otro >> servicio/puerto que no sea SSH? P. ej., servidor de correo sin >cifrado >> (110/25) o cualquier otro que puedas tener configurado en ese equipo. >> >> Lo digo para descartar un problema localizado en ese servicio/ >> aplicativo/puerto o para confirmar que se trata de un problema >> generalizado que afecta a otra combinación de servicios y puertos. > > >Acabo de instalarle Apache y no responde, solamente funciona de modo >local. > >Lo raro que responde al ping... > > >> >> Saludos, >>
¿No tendrás duplicada la IP en la red y te está respondiendo otro equipo? Un tcpdump a ver si está respondiendo ese equipo al Ping y miras si te llega tráfico cuando le tiras el SSH desde otro equipo. Saludos