Serwer SSH nie odpowiada na żądania połączenia

Próbuję skonfigurować serwer SSH na moim komputerze lokalnym za pomocą OpenSSH. Kiedy próbuję SSH ze zdalnego hosta na mój lokalny serwer SSH, serwer SSH nie odpowiada i upłynął limit czasu żądania. Jestem prawie pewien, że istnieje naprawdę oczywiste rozwiązanie tego problemu, które po prostu przeoczam.

Oto, co się dzieje, gdy próbuję SSH do zdalnego hosta:

yoshimi@robots:/$ ssh -vv volt@99.3.26.94
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 99.3.26.94 [99.3.26.94] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: connect to address 99.3.26.94 port 22: Connection timed out
ssh: connect to host 99.3.26.94 port 22: Connection timed out

Gdzie robotsjest mój zdalny host i 99.3.26.94mój lokalny serwer SSH.

SSH działa

volt@arnold:~$ ps -A | grep sshd
 5784 ?        00:00:00 sshd

Gdzie arnoldjest mój lokalny serwer SSH.

Przekazywanie portów jest skonfigurowane na routerze

Mam skonfigurowany router domowy do przekazywania portów 80 i 22 do mojego serwera SSH. Co ciekawe, port 80 działał bez żadnych problemów - przechodzi bezpośrednio do katalogu internetowego Apache. Port 22 - nie tak bardzo.

NMap mówi, że jest filtrowane

yoshimi@robots:/$ nmap -p 22 99.3.26.94

Starting Nmap 6.47 ( http://nmap.org ) at 2015-06-02 14:45 EDT
Nmap scan report for 99-3-26-94.lightspeed.bcvloh.sbcglobal.net (99.3.26.94)
Host is up (0.33s latency).
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

Gdzie robotsjest mój zdalny host i 99.3.26.94mój lokalny serwer SSH.

To nie jest IPTables (myślę)

volt@arnold:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-ssh (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            

... I nie mam żadnych innych zapór ogniowych - jest to stosunkowo świeży netinst Debiana.

Zatem: co to może być? Z pewnością wydaje się, że jest to zapora ogniowa, która po prostu ignoruje ruch, ale jeśli to nie jest router, to nie jest iptables, i nie jest to kolejna zapora na serwerze SSH, ... co tam do cholery jest ??

EDYCJA: Żądanie połączenia z wewnętrznego błędu sieci

yoshimi@robots:/$ ssh volt@192.168.1.90
ssh: connect to host 192.168.1.90 port 22: No route to host

Bardzo rozczarowująca odpowiedź na pytanie

Po odłożeniu tego problemu na jeden dzień i powrocie do niego, poczułem ulgę i zaniepokojenie (bardziej zaniepokojone niż ulgę), gdy stwierdziłem, że wszystko w tajemniczy sposób działa poprawnie.

Więc jaki był problem?

Żadne ustawienia nie zostały zmienione ani dostosowane - nie na routerze, nie na serwerze SSH i na komputerze klienta SSH. Można powiedzieć, że pomimo prawidłowych ustawień router nie obsługiwał prawidłowo ruchu przychodzącego. Biorąc pod uwagę, że złośliwe oprogramowanie routera domowego nie jest tak naprawdę zaprojektowane do radzenia sobie z przekierowaniem portów, biedakowi zajęło trochę czasu, aby wprowadzić niezbędne zmiany.

Ale minęło 6 godzin !!

Tak stary, wiem. Spędziłem cały dzień próbując dowiedzieć się, co było nie tak - i nigdy tego nie znalazłem, ponieważ nie było nic złego. Oczywiście ustawienia routera mogą potrwać 6 godzin, a może nawet dłużej.

Więc skąd mam wiedzieć, czy to mój problem?

Sprytne narzędzie, na które natknąłem się podczas tej eskapady, to tcpdump. Ten chudy chłopczyk wącha dla ciebie ruch, oferując cenny wgląd w to, co się dzieje. Ponadto ma kilka funkcji super filtrowania, które pozwalają zawęzić dokładnie to, na co chcesz spojrzeć. Na przykład polecenie:

tcpdump -i wlan1 port 22 -n -Q inout

Informuje tcpdumpszukać ruchu poprzez interfejs wlan1 ( -i„interface” =), tylko przez port 22, ignorować rozdzielczość nazwa DNS ( -n= „Nie Rozdzielczość name”), i chcemy, aby zobaczyć zarówno ruchu przychodzącego i wychodzącego ( -Qakceptuje in, outlub inout; inoutjest wartością domyślną).

Uruchamiając to polecenie na serwerze SSH podczas próby połączenia za pośrednictwem zdalnego komputera, szybko staje się jasne, gdzie dokładnie leży problem. Istnieją zasadniczo 3 możliwości:

1. Jeśli widzisz ruch przychodzący ze zdalnego komputera, ale nie ma ruchu wychodzącego z lokalnego serwera, problem leży po stronie serwera: prawdopodobnie istnieje reguła zapory ogniowej, którą należy zmienić itp.
2. Jeśli widzisz zarówno przychodzące, jak i wychodzące , ale twój zdalny komputer nie odbiera odpowiedzi, najprawdopodobniej jest to router: zezwala na ruch przychodzący, ale upuszcza pakiety wychodzące.
3. Jeśli w ogóle nie ma ruchu , prawdopodobnie jest to również problem z routerem: SYNpakiety zdalnego komputera są ignorowane i upuszczane przez router, zanim jeszcze dotrą do twojego serwera.

A kiedy odkryjesz, na czym polega problem, poprawka jest (zwykle) trywialna.

Używam Mint (Ubuntu).

Zrobiłem wszystko ... klucz publiczny w prawidłowym formacie w uprawnionych kluczach, chmodding, chowning, restartowanie ssh i sshd itp. Jak to zostało wszędzie udokumentowane.

Dla mnie była to zapora sieciowa ufw. Brak jakiejkolwiek odpowiedzi ssh w ogóle mnie do tego wskazał, ale nie mogłem pingować problemu w obie strony w sieci LAN.

Testowałem przez:

sudo ufw service stop

... i działało idealnie, tzn. dostałem odpowiedź z połączenia ssh.

Zacznij od nowa ufw:

sudo ufw service start

... i dodaj regułę:

sudo ufw allow openssh

Teraz wszystko działa dobrze.

Jeśli, podobnie jak ja, włączyłeś UFW (w Linuksie, w moim przypadku Ubuntu), spróbuj tego:

sudo ufw enable OpenSSH

Umożliwi to OpenSSH w zaporze.

Tylko dla innych:

Musiałem użyć opcji -P w tcpdump zamiast -Q

tcpdump -i wlan1 port 22 -n -P inout

W większości przypadków zapora jest sprawcą. Czy service iptables stopi service ip6tables stop.

Jeśli zatrzymanie usługi nie działa, wykonaj iptable flush.

iptables --flush.

Jeśli jest to VM, zrób to samo na hoście