Não é capaz de ssh para outro computador, mas pode pingar isso?

Question

Incapaz de ssh para outro computador, mas pode pingar? Não tenho certeza do que estou perdendo?
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 [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$ 

    

Answer 1

O servidor não está rodando o sshd (e portanto não está escutando na porta 22) ou tem uma porta de bloqueio do firewall 22 (a porta ssh padrão), ou em casos incrivelmente raros rodando o ssh em alguma outra porta (o que certamente não é o caso).

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

sudo apt-get install openssh-server

E, em caso afirmativo, está em execução:

ps -ef | grep sshd

verifique então se está escutando 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

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

Se ufw mostrar como fechado, execute (novamente um exemplo de debian / ubuntu)

sudo ufw allow 22

    

Answer 2

Meio que um tiro estranho no escuro, mas certifique-se de que seu IP não tenha mudado. Eu tive esse problema uma vez - defini um .bashrc alias alias sshdev='ssh [email protected]' como meu modo típico 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 o IP, então eu estava com sucesso pingando um IP, mas não era a máquina correta. Você pode usar nslookup <IP> para se certificar de que é o nome correto da máquina em que está tentando ssh .

    

Answer 3

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

    

Answer 4

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

    

Answer 5

Dois pensamentos.

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

Answer 6

este comando funcionou para mim. Tente isso.

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

    

Answer 7

Etapas seguidas em geral: 1) ping para o host de destino e verificar e cruzar o endereço IP inserido. 2) Verifique o status do sudo service sshd em ambos os 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.