Nie można ssh na innym komputerze, ale czy można go pingować?

Nie można ssh na innym komputerze, ale czy można go pingować? Nie wiesz, czego mi brakuje?
Korzystanie z routera 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$ 

Serwer albo nie uruchamia sshd (a zatem nie nasłuchuje na porcie 22), albo ma zaporę blokującą port 22 (domyślny port ssh), lub w niewiarygodnie rzadkich przypadkach uruchamia ssh na innym porcie (co prawie na pewno nie jest prawdą) .

Najpierw sprawdź, czy sshd jest zainstalowany (używając przykładów Debiana)

sudo apt-get install openssh-server

A jeśli tak, to czy działa:

ps -ef | grep sshd

następnie sprawdź, czy nasłuchuje na porcie 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

następnie sprawdź reguły zapory ogniowej (to znacznie się różni, więc pokażę przykład 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)

Jeśli ufwpokazuje to jako zamknięte, uruchom (ponownie przykład Debiana / Ubuntu)

sudo ufw allow 22

To trochę dziwne strzelanie w ciemność, ale upewnij się, że twoje IP się nie zmieniło. Miałem ten problem raz - ustawiłem .bashrcalias alias sshdev='ssh me@123.2.3.4'jako mój typowy sposób logowania i pewnego dnia zacząłem otrzymywać następujący błąd:

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

Właśnie mieliśmy awarię zasilania, która zresetowała adresy IP, więc z powodzeniem pingowałem adres IP, ale to nie była właściwa maszyna. Możesz użyć, nslookup <IP>aby upewnić się, że jest to poprawna nazwa komputera, na którą próbujesz sshsię znaleźć.

Gdy pojawi się komunikat „odmowa połączenia”, oznacza to, że demon nie nasłuchuje na tym porcie lub zapora sieciowa odrzuca połączenie. Aby rozwiązać problem, upewnij się, że sshdziała, a lokalne reguły zapory nie odrzucają połączeń przychodzących na tym porcie.

Miałem ten sam problem z Linux Lite. Aby rozwiązać problem, musiałem uzyskać dostęp do Ustawienia> Konfiguracja zapory. Po zalogowaniu się do roota zmieniłem ustawienie przychodzące na Zezwalaj i zadziałało.

Dwie myśli

1. Czy zapora ogniowa umożliwia połączenia przez port 22 z maszyną?
2. Czy działa demon ssh ( sshd)?

to polecenie działało dla mnie. Spróbuj tego.

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

Wykonano ogólnie następujące kroki: 1) ping do hosta docelowego i zweryfikowanie i sprawdzenie adresu IP. 2) Sprawdź status sshd usługi sudo na obu hostach. Jeśli zatrzymany, uruchom usługę sshd. Jeśli pojawi się błąd sshd.service, nie zostanie zainstalowany, zainstaluj openssh-server -> sudo apt install -y openssh-server i zrestartuj sshd.service 3) Wyłączenie zapory ogniowej lub wprowadzenie zmian w plikach konfiguracyjnych należy uznać za ostatnią opcję.