Não é possível fazer o ssh para outro computador, mas pode fazer o ping?

Não é possível fazer o ssh para outro computador, mas pode fazer o ping? Não sabe o que está faltando?
Usando um roteador 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 jeremy@10.0.0.4
ssh: connect to host 10.0.0.4 port 22: Connection refused
bash-3.2$ ssh -p 5900 jeremy@10.0.0.4
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$ 

O servidor não está executando o sshd (e, portanto, não está escutando na porta 22) ou possui um firewall bloqueando a porta 22 (a porta ssh padrão) ou em casos incrivelmente raros, executando o ssh em alguma outra porta (o que quase certamente não é o caso) .

Primeiro verifique se o sshd está instalado (usando exemplos do debian)

sudo apt-get install openssh-server

E se sim, ele está executando:

ps -ef | grep sshd

verifique se está ouvindo a porta 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

então verifique suas regras de firewall (isso varia significativamente, então eu mostrarei um exemplo 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)

Se ufwmostra como fechado, então execute (novamente um exemplo debian / ubuntu)

sudo ufw allow 22

Um tipo estranho no escuro, mas verifique se o seu IP não mudou. Tive esse problema uma vez - defini um .bashrcalias alias sshdev='ssh me@123.2.3.4'como a maneira típica de fazer login e um dia comecei a receber o seguinte erro:

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

Acabamos de ter uma queda de energia no trabalho que redefiniu os IPs, então eu estava conseguindo executar o ping com êxito, mas não era a máquina correta. Você pode usar nslookup <IP>para se certificar de que é o nome correto da máquina que você está tentando sshinserir.

Quando você recebe a mensagem "conexão recusada", isso significa que um daemon não está escutando nessa porta ou um firewall está rejeitando a conexão. Para resolver o problema, verifique se sshestá em execução e se as regras do firewall local não estão rejeitando as conexões de entrada nessa porta.

Eu tive o mesmo problema com o Linux Lite. Para corrigir o problema, tive que acessar Configurações> Configuração do firewall. Depois de entrar no root, alterei a configuração de entrada para Allow e funcionou.

Dois pensamentos.

1. O firewall permite conexões na porta 22 com a máquina?
2. O ssh daemon ( sshd) está em execução?

esse comando funcionou para mim. Tente isso.

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

Etapas seguidas em geral: 1) execute ping no host de destino e verifique e verifique o endereço IP inserido. 2) Verifique o status do serviço sudo sshd nos dois hosts. Se parado, inicie o serviço sshd. Se você receber um erro sshd.service não encontrado, instale o openssh-server -> sudo apt install -y openssh-server e reinicie o sshd.service 3) Desabilitar o firewall ou fazer alterações nos arquivos de configuração deve ser considerado a última opção.