¿No puede enviar ssh a otra computadora, pero puede hacer ping?

¿No puede enviar ssh a otra computadora pero puede hacer ping? ¿No estás seguro de lo que me estoy perdiendo?
Usando un enrutador Netgear

bash-3.2$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet6 ::1 prefixlen 128 
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
        inet 127.0.0.1 netmask 0xff000000 
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        ether xx:xx:xx:xx:xx:xx 
        media: autoselect (none)
        status: inactive
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        ether xx:xx:xx:xx:xx:xx 
        inet6 xxxx::xxxx:xxxx:xxxx:xxxxxx prefixlen 64 scopeid 0x5 
        inet 10.0.0.3 netmask 0xffffff00 broadcast 10.0.0.255
        media: autoselect
        status: active
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
        lladdr xx:xx:xx:xx:xx:xx:xx:xx 
        media: autoselect <full-duplex>
        status: inactive
bash-3.2$ ssh [email protected]
ssh: connect to host 10.0.0.4 port 22: Connection refused
bash-3.2$ ssh -p 5900 [email protected]
ssh: connect to host 10.0.0.4 port 5900: Connection refused
bash-3.2$ ping 10.0.0.3
PING 10.0.0.3 (10.0.0.3): 56 data bytes
64 bytes from 10.0.0.3: icmp_seq=0 ttl=64 time=0.046 ms
64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=0.079 ms
64 bytes from 10.0.0.3: icmp_seq=2 ttl=64 time=0.078 ms
64 bytes from 10.0.0.3: icmp_seq=3 ttl=64 time=0.077 ms
64 bytes from 10.0.0.3: icmp_seq=4 ttl=64 time=0.079 ms
64 bytes from 10.0.0.3: icmp_seq=5 ttl=64 time=0.081 ms
64 bytes from 10.0.0.3: icmp_seq=6 ttl=64 time=0.078 ms
^C
--- 10.0.0.3 ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.046/0.074/0.081/0.011 ms
bash-3.2$ ping 10.0.0.4
PING 10.0.0.4 (10.0.0.4): 56 data bytes
64 bytes from 10.0.0.4: icmp_seq=0 ttl=64 time=2.667 ms
64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=2.675 ms
64 bytes from 10.0.0.4: icmp_seq=2 ttl=64 time=2.969 ms
64 bytes from 10.0.0.4: icmp_seq=3 ttl=64 time=2.663 ms
64 bytes from 10.0.0.4: icmp_seq=4 ttl=64 time=2.723 ms
^C
--- 10.0.0.4 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.663/2.739/2.969/0.117 ms
bash-3.2$ 

El servidor no está ejecutando sshd (y, por lo tanto, no está escuchando en el puerto 22) o tiene un puerto de bloqueo de firewall 22 (el puerto ssh predeterminado), o en casos increíblemente raros ejecutando ssh en algún otro puerto (que seguramente no es el caso) .

Primero verifique para asegurarse de que sshd esté instalado (usando ejemplos de Debian)

sudo apt-get install openssh-server

Y si es así, se está ejecutando:

ps -ef | grep sshd

luego verifique si está escuchando el puerto 22

sudo netstat -nlp | grep :22
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      946/sshd
tcp6       0      0 :::22                   :::*                    LISTEN      946/sshd

luego verifique las reglas de su firewall (esto varía significativamente, así que le mostraré un ejemplo de debian / ubuntu / etc):

sudo ufw status

sudo ufw show listening
tcp:
  22 * (sshd)
  24224 * (ruby)
tcp6:
  22 * (sshd)
  8080 * (java)
udp:
  123 10.X.Y.Z (ntpd)
  123 * (ntpd)
  18649 * (dhclient)
  24224 * (ruby)
  34131 * (ruby)
  60001 10.87.43.24 (mosh-server)
  68 * (dhclient)
udp6:
  123 fe80::1031:AAAA:BBBB:CCCC (ntpd)
  123 * (ntpd)
  48573 * (dhclient)

Si lo ufwmuestra como cerrado, ejecute (nuevamente un ejemplo de debian / ubuntu)

sudo ufw allow 22

Una especie de disparo extraño en la oscuridad, pero asegúrese de que su IP no haya cambiado. Tuve este problema una vez: configuré un .bashrcalias alias sshdev='ssh [email protected]'como mi forma típica de iniciar sesión y un día comencé a recibir el siguiente error:

ME-M-216C:~ me$ sshdev 
ssh: connect to host 123.2.3.4 port 22: Connection refused

Acabamos de tener un corte de energía en el trabajo que restableció las IP, así que estaba haciendo ping con éxito a una IP pero no era la máquina correcta. Puede usar nslookup <IP>para asegurarse de que es el nombre correcto de la máquina en el que está intentando sshingresar.

Cuando recibe el mensaje "conexión rechazada", eso significa que un demonio no está escuchando en ese puerto o un firewall está rechazando la conexión. Para resolver el problema, asegúrese de que se sshesté ejecutando y que las reglas del firewall local no rechacen las conexiones entrantes en ese puerto.

Tuve el mismo problema con Linux Lite. Para solucionar el problema, tuve que acceder a Configuración> Configuración de firewall. Después de iniciar sesión en root, cambié la configuración entrante a Permitir y funcionó.

Dos pensamientos

1. ¿El firewall permite conexiones en el puerto 22 a la máquina?
2. ¿Se está sshdejecutando ssh daemon ( )?

Este comando funcionó para mí. Prueba esto.

update-rc.d -f ssh enable 2 3 4 5

Pasos seguidos en general: 1) haga ping al host de destino y verifique y verifique la dirección IP ingresada. 2) Verifique el estado de sudo service sshd en ambos hosts. Si se detuvo, inicie el servicio sshd. Si obtiene un error sshd.service no encontrado, instale openssh-server -> sudo apt install -y openssh-server y reinicie sshd.service 3) Deshabilitar el firewall o realizar cambios en los archivos de configuración debería considerarse la última opción.