date:20210517

Re: ssh no conecta (Bullseye en ambos equipos) * SOLUCIONADO * era por el ufw

2021-05-17 Por tema Walter Omar Dari

Hola gente, quedó SOLUCIONADO, era el ufw, no tenía idea que estaba 
instalado en ese equipo. Pero lo cierto es que comenzó a actuar a partir 
de la actualización a bullseye, con buster no bloqueaba nada. Es muy raro.


Gracias a OddieX por la ayuda y a todos los que respondieron, aprendí 
unas cuantas cosas para chequear que nunca había tenido que usar.


La solución: descubrí que había una interfaz gráfica para el ufw en el 
equipo en cuestión, ni bien la abrí vi que estaba todo denegado, así que 
cambié las opciones y ahora puedo ingresar.


La verdad que no recuerdo haber instalado ese firewall ni haberlo 
configurado nunca. Espero que no sean los años... ;-)


https://help.ubuntu.com/community/UFW

Saludos a todos y gracias nuevamente.



El 17/5/21 a las 15:16, OddieX escribió:

El lun, 17 may 2021 a las 15:04, Walter Omar Dari
() escribió:


Hola...

El 17/5/21 a las 12:51, OddieX escribió:



El lun., 17 de mayo de 2021 12:48, Walter Omar Dari mailto:wlin...@gmail.com>> escribió:

 Hola, lo que me faltaba probar...

 El 16/5/21 a las 03:52, Camaleón escribió:
  > El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:
  >
  > [...]
  >
  >
  > 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.

 Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay
 problemas.


  >
  > Saludos,
  >

 --




 Fijate en login.Defs q no encuentra iptables pq desde buster en
 adelante cambiaron los env path... Sino whereis iptables y ejecutalo
 con path completo...



Funcionó indicando la ruta completa, aquí va la salida, yo no veo
inconvenientes, pero no estoy muy ducho con estos (disculpas porque es
bastante larga)...


Chain INPUT (policy DROP)
target prot opt source   destination
ufw-before-logging-input  all  --  anywhere anywhere
ufw-before-input  all  --  anywhere anywhere
ufw-after-input  all  --  anywhere anywhere
ufw-after-logging-input  all  --  anywhere anywhere
ufw-reject-input  all  --  anywhere anywhere
ufw-track-input  all  --  anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source   destination
ufw-before-logging-forward  all  --  anywhere anywhere

ufw-before-forward  all  --  anywhere anywhere
ufw-after-forward  all  --  anywhere anywhere
ufw-after-logging-forward  all  --  anywhere anywhere

ufw-reject-forward  all  --  anywhere anywhere
ufw-track-forward  all  --  anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
ufw-before-logging-output  all  --  anywhere anywhere

ufw-before-output  all  --  anywhere anywhere
ufw-after-output  all  --  anywhere anywhere
ufw-after-logging-output  all  --  anywhere anywhere
ufw-reject-output  all  --  anywhere anywhere
ufw-track-output  all  --  anywhere anywhere

Chain ufw-after-forward (1 references)
target prot opt source   destination

Chain ufw-after-input (1 references)
target prot opt source   destination
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:netbios-ns
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:netbios-dgm
ufw-skip-to-policy-input  tcp  --  anywhere anywhere
   tcp dpt:netbios-ssn
ufw-skip-to-policy-input  tcp  --  anywhere anywhere
   tcp dpt:microsoft-ds
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:bootps
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:bootpc
ufw-skip-to-policy-input  all  --  anywhere anywhere
   ADDRTYPE match dst-type BROADCAST

Chain ufw-after-logging-forward (1 references)
target prot opt source   destination
LOGall  --  anywhere anywhere limit: avg
3/min burst 10 LOG level warning prefix "[UFW BLOCK] "

Chain ufw-after-logging-input (1 references)
target prot opt source   destination

Chain ufw-after-logging-output (1 references)
target prot opt source   destination

Chain ufw-after-output (1 references)
target prot opt source   destination

Chain ufw-before-forward (1 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere ctstate
RELATED,ESTABLISHED
ACCEPT icmp --  anywhere anywhere icmp
destination-unreachable
ACCEPT icmp --  anywhere anywhere icmp
time-exceeded
ACCEPT icmp --  anywhere anywhere

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Walter Omar Dari





El 17/5/21 a las 15:16, OddieX escribió:

El lun, 17 may 2021 a las 15:04, Walter Omar Dari
() escribió:


Hola...

El 17/5/21 a las 12:51, OddieX escribió:



El lun., 17 de mayo de 2021 12:48, Walter Omar Dari mailto:wlin...@gmail.com>> escribió:

 Hola, lo que me faltaba probar...

 El 16/5/21 a las 03:52, Camaleón escribió:
  > El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:
  >
  > [...]
  >
  >
  > 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.

 Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay
 problemas.


  >
  > Saludos,
  >

 --




 Fijate en login.Defs q no encuentra iptables pq desde buster en
 adelante cambiaron los env path... Sino whereis iptables y ejecutalo
 con path completo...



Funcionó indicando la ruta completa, aquí va la salida, yo no veo
inconvenientes, pero no estoy muy ducho con estos (disculpas porque es
bastante larga)...


Chain INPUT (policy DROP)
target prot opt source   destination
ufw-before-logging-input  all  --  anywhere anywhere
ufw-before-input  all  --  anywhere anywhere
ufw-after-input  all  --  anywhere anywhere
ufw-after-logging-input  all  --  anywhere anywhere
ufw-reject-input  all  --  anywhere anywhere
ufw-track-input  all  --  anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source   destination
ufw-before-logging-forward  all  --  anywhere anywhere

ufw-before-forward  all  --  anywhere anywhere
ufw-after-forward  all  --  anywhere anywhere
ufw-after-logging-forward  all  --  anywhere anywhere

ufw-reject-forward  all  --  anywhere anywhere
ufw-track-forward  all  --  anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
ufw-before-logging-output  all  --  anywhere anywhere

ufw-before-output  all  --  anywhere anywhere
ufw-after-output  all  --  anywhere anywhere
ufw-after-logging-output  all  --  anywhere anywhere
ufw-reject-output  all  --  anywhere anywhere
ufw-track-output  all  --  anywhere anywhere

Chain ufw-after-forward (1 references)
target prot opt source   destination

Chain ufw-after-input (1 references)
target prot opt source   destination
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:netbios-ns
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:netbios-dgm
ufw-skip-to-policy-input  tcp  --  anywhere anywhere
   tcp dpt:netbios-ssn
ufw-skip-to-policy-input  tcp  --  anywhere anywhere
   tcp dpt:microsoft-ds
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:bootps
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:bootpc
ufw-skip-to-policy-input  all  --  anywhere anywhere
   ADDRTYPE match dst-type BROADCAST

Chain ufw-after-logging-forward (1 references)
target prot opt source   destination
LOGall  --  anywhere anywhere limit: avg
3/min burst 10 LOG level warning prefix "[UFW BLOCK] "

Chain ufw-after-logging-input (1 references)
target prot opt source   destination

Chain ufw-after-logging-output (1 references)
target prot opt source   destination

Chain ufw-after-output (1 references)
target prot opt source   destination

Chain ufw-before-forward (1 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere ctstate
RELATED,ESTABLISHED
ACCEPT icmp --  anywhere anywhere icmp
destination-unreachable
ACCEPT icmp --  anywhere anywhere icmp
time-exceeded
ACCEPT icmp --  anywhere anywhere icmp
parameter-problem
ACCEPT icmp --  anywhere anywhere icmp
echo-request
ufw-user-forward  all  --  anywhere anywhere

Chain ufw-before-input (1 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere ctstate
RELATED,ESTABLISHED
ufw-logging-deny  all  --  anywhere anywhere
ctstate INVALID
DROP   all  --  anywhere anywhere ctstate
INVALID
ACCEPT icmp --  anywhere anywhere icmp
destination-unreachable
ACCEPT icmp --  anywhere anywhere icmp
time-exceeded
ACCEPT icmp --  anywhere

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Walter Omar Dari


Hola...

El 17/5/21 a las 15:15, Ramses escribió:

El 17 de mayo de 2021 19:49:11 CEST, Walter Omar Dari  
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  iptables1.8.7-1  amd64administration 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.


No, no está duplicada, ya está comprobado. Gracias !





Saludos

.



--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema OddieX

El lun, 17 may 2021 a las 15:04, Walter Omar Dari
() escribió:
>
> Hola...
>
> El 17/5/21 a las 12:51, OddieX escribió:
> >
> >
> > El lun., 17 de mayo de 2021 12:48, Walter Omar Dari  > > escribió:
> >
> > Hola, lo que me faltaba probar...
> >
> > El 16/5/21 a las 03:52, Camaleón escribió:
> >  > El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:
> >  >
> >  > [...]
> >  >
> >  >
> >  > 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.
> >
> > Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay
> > problemas.
> >
> >
> >  >
> >  > Saludos,
> >  >
> >
> > --
> >
> >
> >
> >
> > Fijate en login.Defs q no encuentra iptables pq desde buster en
> > adelante cambiaron los env path... Sino whereis iptables y ejecutalo
> > con path completo...
> >
>
> Funcionó indicando la ruta completa, aquí va la salida, yo no veo
> inconvenientes, pero no estoy muy ducho con estos (disculpas porque es
> bastante larga)...
>
>
> Chain INPUT (policy DROP)
> target prot opt source   destination
> ufw-before-logging-input  all  --  anywhere anywhere
> ufw-before-input  all  --  anywhere anywhere
> ufw-after-input  all  --  anywhere anywhere
> ufw-after-logging-input  all  --  anywhere anywhere
> ufw-reject-input  all  --  anywhere anywhere
> ufw-track-input  all  --  anywhere anywhere
>
> Chain FORWARD (policy DROP)
> target prot opt source   destination
> ufw-before-logging-forward  all  --  anywhere anywhere
>
> ufw-before-forward  all  --  anywhere anywhere
> ufw-after-forward  all  --  anywhere anywhere
> ufw-after-logging-forward  all  --  anywhere anywhere
>
> ufw-reject-forward  all  --  anywhere anywhere
> ufw-track-forward  all  --  anywhere anywhere
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
> ufw-before-logging-output  all  --  anywhere anywhere
>
> ufw-before-output  all  --  anywhere anywhere
> ufw-after-output  all  --  anywhere anywhere
> ufw-after-logging-output  all  --  anywhere anywhere
> ufw-reject-output  all  --  anywhere anywhere
> ufw-track-output  all  --  anywhere anywhere
>
> Chain ufw-after-forward (1 references)
> target prot opt source   destination
>
> Chain ufw-after-input (1 references)
> target prot opt source   destination
> ufw-skip-to-policy-input  udp  --  anywhere anywhere
>   udp dpt:netbios-ns
> ufw-skip-to-policy-input  udp  --  anywhere anywhere
>   udp dpt:netbios-dgm
> ufw-skip-to-policy-input  tcp  --  anywhere anywhere
>   tcp dpt:netbios-ssn
> ufw-skip-to-policy-input  tcp  --  anywhere anywhere
>   tcp dpt:microsoft-ds
> ufw-skip-to-policy-input  udp  --  anywhere anywhere
>   udp dpt:bootps
> ufw-skip-to-policy-input  udp  --  anywhere anywhere
>   udp dpt:bootpc
> ufw-skip-to-policy-input  all  --  anywhere anywhere
>   ADDRTYPE match dst-type BROADCAST
>
> Chain ufw-after-logging-forward (1 references)
> target prot opt source   destination
> LOGall  --  anywhere anywhere limit: avg
> 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "
>
> Chain ufw-after-logging-input (1 references)
> target prot opt source   destination
>
> Chain ufw-after-logging-output (1 references)
> target prot opt source   destination
>
> Chain ufw-after-output (1 references)
> target prot opt source   destination
>
> Chain ufw-before-forward (1 references)
> target prot opt source   destination
> ACCEPT all  --  anywhere anywhere ctstate
> RELATED,ESTABLISHED
> ACCEPT icmp --  anywhere anywhere icmp
> destination-unreachable
> ACCEPT icmp --  anywhere anywhere icmp
> time-exceeded
> ACCEPT icmp --  anywhere anywhere icmp
> parameter-problem
> ACCEPT icmp --  anywhere anywhere icmp
> echo-request
> ufw-user-forward  all  --  anywhere anywhere
>
> Chain ufw-before-input (1 references)
> target prot opt source   destination
> ACCEPT all  --  anywhere anywhere
> ACCEPT all  --  anywhere anywhere ctstate
> RELATED,ESTABLISHED
> ufw-logging-deny  all  --  anywhere anywhere
> ctstate INVALID
> DROP   all  --  anywhere anywhere

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Ramses

El 17 de mayo de 2021 19:49:11 CEST, Walter Omar Dari  
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  iptables1.8.7-1  amd64administration 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

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Walter Omar Dari


Hola...

El 17/5/21 a las 12:51, OddieX escribió:



El lun., 17 de mayo de 2021 12:48, Walter Omar Dari > escribió:


Hola, lo que me faltaba probar...

El 16/5/21 a las 03:52, Camaleón escribió:
 > El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:
 >
 > [...]
 >
 >
 > 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.

Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay
problemas.


 >
 > Saludos,
 >

-- 





Fijate en login.Defs q no encuentra iptables pq desde buster en
adelante cambiaron los env path... Sino whereis iptables y ejecutalo
con path completo...



Funcionó indicando la ruta completa, aquí va la salida, yo no veo 
inconvenientes, pero no estoy muy ducho con estos (disculpas porque es 
bastante larga)...



Chain INPUT (policy DROP)
target prot opt source   destination
ufw-before-logging-input  all  --  anywhere anywhere
ufw-before-input  all  --  anywhere anywhere
ufw-after-input  all  --  anywhere anywhere
ufw-after-logging-input  all  --  anywhere anywhere
ufw-reject-input  all  --  anywhere anywhere
ufw-track-input  all  --  anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source   destination
ufw-before-logging-forward  all  --  anywhere anywhere 


ufw-before-forward  all  --  anywhere anywhere
ufw-after-forward  all  --  anywhere anywhere
ufw-after-logging-forward  all  --  anywhere anywhere 


ufw-reject-forward  all  --  anywhere anywhere
ufw-track-forward  all  --  anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
ufw-before-logging-output  all  --  anywhere anywhere 


ufw-before-output  all  --  anywhere anywhere
ufw-after-output  all  --  anywhere anywhere
ufw-after-logging-output  all  --  anywhere anywhere
ufw-reject-output  all  --  anywhere anywhere
ufw-track-output  all  --  anywhere anywhere

Chain ufw-after-forward (1 references)
target prot opt source   destination

Chain ufw-after-input (1 references)
target prot opt source   destination
ufw-skip-to-policy-input  udp  --  anywhere anywhere 
 udp dpt:netbios-ns
ufw-skip-to-policy-input  udp  --  anywhere anywhere 
 udp dpt:netbios-dgm
ufw-skip-to-policy-input  tcp  --  anywhere anywhere 
 tcp dpt:netbios-ssn
ufw-skip-to-policy-input  tcp  --  anywhere anywhere 
 tcp dpt:microsoft-ds
ufw-skip-to-policy-input  udp  --  anywhere anywhere 
 udp dpt:bootps
ufw-skip-to-policy-input  udp  --  anywhere anywhere 
 udp dpt:bootpc
ufw-skip-to-policy-input  all  --  anywhere anywhere 
 ADDRTYPE match dst-type BROADCAST


Chain ufw-after-logging-forward (1 references)
target prot opt source   destination
LOGall  --  anywhere anywhere limit: avg 
3/min burst 10 LOG level warning prefix "[UFW BLOCK] "


Chain ufw-after-logging-input (1 references)
target prot opt source   destination

Chain ufw-after-logging-output (1 references)
target prot opt source   destination

Chain ufw-after-output (1 references)
target prot opt source   destination

Chain ufw-before-forward (1 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere ctstate 
RELATED,ESTABLISHED
ACCEPT icmp --  anywhere anywhere icmp 
destination-unreachable
ACCEPT icmp --  anywhere anywhere icmp 
time-exceeded
ACCEPT icmp --  anywhere anywhere icmp 
parameter-problem
ACCEPT icmp --  anywhere anywhere icmp 
echo-request

ufw-user-forward  all  --  anywhere anywhere

Chain ufw-before-input (1 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere ctstate 
RELATED,ESTABLISHED
ufw-logging-deny  all  --  anywhere anywhere 
ctstate INVALID
DROP   all  --  anywhere anywhere ctstate 
INVALID
ACCEPT icmp --  anywhere anywhere icmp 
destination-unreachable
ACCEPT icmp --  anywhere anywhere icmp 
time-exceeded
ACCEPT icmp --  anywhere anywhere icmp 
parameter-problem
ACCEPT icmp --  anywhere anywhere

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Walter Omar Dari





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  iptables1.8.7-1  amd64administration 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,



--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Camaleón

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  iptables1.8.7-1  amd64administration 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.

Saludos,

-- 
Camaleón

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema OddieX

El lun., 17 de mayo de 2021 12:48, Walter Omar Dari 
escribió:

> Hola, lo que me faltaba probar...
>
> El 16/5/21 a las 03:52, Camaleón escribió:
> > El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:
> >
> > [...]
> >
> >
> > 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.
>
> Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay
> problemas.
>
>
> >
> > Saludos,
> >
>
> --
>
> Walter O. Dari
>
> http://swcomputacion.com/
> http://swcomputacion.com/sistemas/
> https://facebook.com/swcomputacion/
> https://facebook.com/sistemasSW/
>
> Nuestros horarios:
> L a V 8 a 13 hs.
> S 11 a 14 hs.
>
> WhatsApp:
> 2396 577140 (no se atienden llamadas)
>
>
>
> Fijate en login.Defs q no encuentra iptables pq desde buster en adelante
> cambiaron los env path... Sino whereis iptables y ejecutalo con path
> completo...

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Walter Omar Dari


Hola, lo que me faltaba probar...

El 16/5/21 a las 03:52, Camaleón escribió:

El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:

[...] 



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.


Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay 
problemas.





Saludos,



--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Walter Omar Dari


Hola...

El 16/5/21 a las 03:52, Camaleón escribió:

El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:


Hola Camaleón, cómo va ?...


:-)


El 15/5/21 a las 14:27, Camaleón escribió:

Además d elo que te han comentado, revisa las opciones de configuración
de SSH en el sistema donde has puesto testing, quizá alguna opción te
esté dando guerra.



Los archivos de configuración, los contenidos en /etc/ssh/ son prácticamente
idénticos en los dos equipos, salvo los archivos .key


Ok...


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  iptables1.8.7-1  amd64administration tools for 
packet filtering and NAT


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  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
root@debwal:/home/dari#






Prueba a conectarte desde el propio equipo (ssh root@localhost).


Conecta perfectamente


Me desorienta que no me de algún mensaje más, alguna pista en el modo
"verbose"...


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 !




Saludos,



Saludos,

--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Walter Omar Dari


Hola Zeque...

El 15/5/21 a las 20:53, Zeque escribió:

Walter,

Es raro lo del timeout, probaste hacer un telnet al puerto?
nc -v 192.168.0.8 22



Revistaste el archivo hosts.deny hosts.allow que nada haya cambiado?



Chequea también las reglas de firewall
iptables -L


Te dejo los resultados más uno que me sugirió Camaleon


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  iptables1.8.7-1  amd64administration tools for 
packet filtering and NAT


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  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
root@debwal:/home/dari#


Saludos,



Saludos!
Zeque

El 15 de mayo de 2021 12:49:37 ART, Walter Omar Dari  
escribió:


Hola gente:

Me quiero conectar a un equipo de la red local que antes tenía Buster y
no había problemas, pero no puedo a partir de que le instalé Bullseye.
No se si será por Bullseye u otro motivo.

Cuando quiero conectar queda así...

dari@debwal:~$ ssh 192.168.0.8 -vvv
OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k  25 Mar 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include
/etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.0.8 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' ->
'/home/wodari/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' ->
'/home/wodari/.ssh/known_hosts2'
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.


En el equipo al que me quiero conectar, el puerto 22 parece estar bien...

# netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address
State   PID/Program name
tcp0  0 127.0.0.1:530.0.0.0:*
LISTEN  652/connmand
tcp0  0 0.0.0.0:22  0.0.0.0:*
LISTEN  586057/sshd: /usr/s
tcp0  0 127.0.0.1:631   0.0.0.0:*
LISTEN  523630/cupsd
tcp0  0 0.0.0.0:44025   0.0.0.0:*
LISTEN  -
tcp0  0 127.0.0.1:250.0.0.0:*
LISTEN  1146/exim4
tcp0  0 0.0.0.0:17500   0.0.0.0:*
LISTEN  581546/dropbox
tcp0  0 127.0.0.1:17600 0.0.0.0:*
LISTEN  581546/dropbox
tcp0  0 127.0.0.1:17603 0.0.0.0:*
LISTEN  581546/dropbox
tcp0  0 0.0.0.0:111 0.0.0.0:*
LISTEN  1/init
tcp6   0  0 :::1716 :::*
LISTEN  580502/kdeconnectd
tcp6   0  0 ::1:53  :::*
LISTEN  652/connmand
tcp6   0  0 :::22   :::*
LISTEN  586057/sshd: /usr/s
tcp6   0  0 ::1:631 :::*
LISTEN  523630/cupsd
tcp6   0  0 :::41785:::*
LISTEN  -
tcp6   0  0 ::1:25  :::*
LISTEN  1146/exim4
tcp6   0  0 :::17500:::*
LISTEN  581546/dropbox
tcp6   0  0 :::111  :::*
LISTEN  1/init

Los archivos de configuración ssh_config y sshd_config están iguales en
los dos equipos, en directorios ssh_config.d y sshd_config.d estàn
vacìos en ambos equipos.

Desde el equipo al cual me quiero comunicar, al mío no tengo problemas,
ssh conecta sin problemas, el tema es cuando es al revés.

Alguien me puede dar alguna pista ?

Muchas gracias,
-- 


Walter O. Dari

http://swcomputacion.com/ 
http://swcomputacion.com/sistemas/ 
https://facebook.com/swcomputacion/

https://facebook.com/sistemasSW/ 

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)



--

Walter O.

Re: ssh no conecta (Bullseye en ambos equipos) * SOLUCIONADO * era por el ufw

Re: ssh no conecta (Bullseye en ambos equipos)

Re: ssh no conecta (Bullseye en ambos equipos)

Re: ssh no conecta (Bullseye en ambos equipos)

Re: ssh no conecta (Bullseye en ambos equipos)

Re: ssh no conecta (Bullseye en ambos equipos)

Re: ssh no conecta (Bullseye en ambos equipos)

Re: ssh no conecta (Bullseye en ambos equipos)

Re: ssh no conecta (Bullseye en ambos equipos)

Re: ssh no conecta (Bullseye en ambos equipos)

Re: ssh no conecta (Bullseye en ambos equipos)

Re: ssh no conecta (Bullseye en ambos equipos)

12 matches

Site Navigation

Mail list logo

Footer information