Re: ssh no conecta (Bullseye en ambos equipos)
El 17 de mayo de 2021 19:49:11 CEST, Walter Omar Dari <wlinuxw@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
Reply to: