ssh_exchange_identification: Połączenie zamknięte przez zdalny host (nieużywający hosts.deny)

74

Ja nie używając hosts.allowlub hosts.deny, jeszcze bardziej SSH działa od mojego okna automatyczna (taki sam laptop, inny dysk twardy), ale nie moim komputerze z systemem Linux.

ssh -vvv root@host -p port daje:

OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to host [host] port <port>.
debug1: Connection established.
debug1: identity file /home/torxed/.ssh/id_dsa type -1
debug1: identity file /home/torxed/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6
ssh_exchange_identification: read: Connection reset by peer

Na komputerze z systemem Windows wszystko działa poprawnie, więc sprawdziłem logi bezpieczeństwa, a wiersze tam są identyczne, serwer nie traktuje dwóch różnych „maszyn” i oba są dozwolone przez uwierzytelnianie za pomocą klucza publicznego.

To prowadzi do wniosku, że to musi być problem z moim lokalnym laptopem ArchLinux .. ale co?

[torxed@archie ~]$ cat .ssh/known_hosts 
[torxed@archie ~]$ 

Więc to nie jest problem ..

[torxed@archie ~]$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

Brak konfliktów z ustawieniami zapory (na razie) ..

[torxed@archie ~]$ ls -la .ssh/
total 20
drwx------  2 torxed users 4096 Sep  3  2013 .
drwx------ 51 torxed users 4096 May 11 11:11 ..
-rw-------  1 torxed users 1679 Sep  3  2013 id_rsa
-rw-r--r--  1 torxed users  403 Sep  3  2013 id_rsa.pub
-rw-r--r--  1 torxed users  170 May 11 11:21 known_hosts

Uprawnienia wydają się być w porządku (to samo na serwerze). Próbowano także bez konfiguracji /etc/ssh/ssh_configz tym samym wynikiem, z wyjątkiem wielu automatycznych konfiguracji wykonywanych w kliencie, które kończą się tym samym błędem.

Torxed
źródło
proszę podać wynik działania iptables-save|grep -v '^#', który obejmie inne tabele (np. nati mangle). Jeśli są puste, po prostu to zaznacz. Twoje iptableswyniki powyżej są domyślnie ograniczone do filtertabeli. Ponadto na serwerze SSH uruchom SSH na alternatywnym porcie takim jak ten i daj wynik debugowania.
0xC0000022L
@ 0xC0000022L gist.github.com/Torxed/d7a5a556c527ffbb609d i gist.github.com/Torxed/1fd9b5b0c276629caf30 i jeśli chodzi o zaporę ogniową, SSH działa na moim dysku Windows (ponownie, ten sam laptop Ergo Mac i IP), ale nie na moim dysku Linux.
Torxed
jeszcze dwie rzeczy. Musisz połączyć się z instancją na alternatywnym porcie. W przeciwnym razie nie będziesz w stanie zobaczyć możliwych problemów. Jeśli chodzi o Windows vs. Linux, czy jedna z nich może używać IPv6 ( ip6tables-save)?
0xC0000022L
@ 0xC0000022L Bardzo mi przykro. Podłączyłem się do niewłaściwego adresu IP .. Uruchamiając SSH na porcie 8080, dlatego ten problem pojawił się podczas łączenia się z hostem obsługującym pamięć podręczną na porcie 8080> _ <
Torxed
1
Zdarzyło mi się to sporadycznie, gdy mój serwer został trafiony przez przypadkowego napastnika próbującego sshd z użyciem siły. Naprawiono przez dodanie reguł zapory sieciowej, aby usunąć połączenia z atakującego.
Andrew Hows,

Odpowiedzi:

60

Jeśli wykluczyłeś jakiekolwiek czynniki „zewnętrzne”, następujący zestaw kroków zwykle pomaga go zawęzić. Chociaż nie odpowiada to bezpośrednio na twoje pytanie, może pomóc w wyśledzeniu przyczyny błędu.

Rozwiązywanie problemów sshd

To, co ogólnie uważam za bardzo przydatne w takich przypadkach, to zacząć sshdbez pozwalania na demonizację. Problem w moim przypadku polegał na tym, że ani syslognie auth.logwykazało niczego znaczącego.

Kiedy uruchomiłem go z terminala, otrzymałem:

# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

Dużo lepiej! Ten komunikat o błędzie pozwolił mi zobaczyć, co jest nie tak, i naprawić to. Żaden z plików dziennika nie zawierał tego wyniku.

Uwaga: przynajmniej w Ubuntu $(which sshd)jest to najlepsza metoda spełnienia sshdwymogu bezwzględnej ścieżki. W przeciwnym razie będziesz się następujący błąd: sshd re-exec requires execution with an absolute path. Te -p 10222marki sshdsłuchać tego alternatywnego portu, zastępując plik konfiguracyjny - to jest tak, że nie kolidują z potencjalnie uruchomionych sshdinstancji. Wybierz wolny port tutaj.

Wreszcie: podłączenie do alternatywnego portu ( ssh -p 10222 user@server).

Ta metoda pomogła mi wiele razy w znalezieniu problemów, czy to uwierzytelniania, czy innych typów. Aby uzyskać naprawdę pełne dane wyjściowe stdout, użyj $(which sshd) -Ddddp 10222(zwróć uwagę na dodane w ddcelu zwiększenia szczegółowości). Aby uzyskać więcej informacji na temat sprawdzania poprawności debugowania man sshd.

0xC0000022L
źródło
Podłączyłem się do niewłaściwego adresu IP, ale to mnie uruchomiło. Zauważyłem, że żadna z moich prób połączenia nie pojawiła się w
wynikach
2
$ (który sshd) -Ddp 10222 pozwala mi wreszcie zobaczyć, co było przyczyną mojego problemu. Wielkie dzięki!
Cuga
9

Możesz także mieć hosta, którego pamięć jest tak mocno podzielona, ​​że ​​nie może przydzielić stronie ciągłej pamięci, aby rozwidlić proces hostowania sesji SSH.

W takim przypadku możesz otrzymać jeden z komunikatów:

ssh_exchange_identification: read: Connection reset by peer

lub:

Connection closed by aaa.bbb.ccc.ddd

w zależności od tego, jak daleko host się wydostaje, zanim się wyskoczy.

Jeśli oczywistą przyczyną jest fragmentacja pamięci, rozwiązaniem jest uzyskanie dostępu do serwera za pomocą innych środków i zrestartowanie niektórych istotnych usług. Odkryłem, że Apache i MySQL są winowajcami maszyn wirtualnych, ponieważ maszyny wirtualne nie mają partycji wymiany. W przeciwnym razie zrestartuj host.

gerrit_hoekstra
źródło
6

Na wszelki wypadek, bo mi się to przydarzyło. Upewnij się, że sshd działa na hoście!

To głupia porażka, ale może być naprawdę twoim problemem.

txomon
źródło
10
Jeśli sshdnie było uruchomione, połączenie nie zostanie zamknięte, ale odmówi (spróbuj ssh -p someportwithoutsshd localhost).
Anthon
4
Cóż, moja sprawa nie była bezpośrednim połączeniem. Stworzyłem tunel zwrotny do maszyny nie nasłuchującej, i to było wyjście w połączeniu klienta ssh.
txomon
1
głupie mnie też nie wiem, że nie mam uruchomionego sshd, naprawiłem to instalując openssh-server
Bryan Estrito
4

Odkryłem, że ten błąd był spowodowany przekroczeniem sesji ssh na serwerze. Znalazłem hostów próbujących się połączyć i zabiłem wszystkie sesje od wszystkich klientów. Problem rozwiązany po wyczyszczeniu wszystkich sesji.

NvipiN
źródło
20
Jak to zrobiłeś?
Przerwano
4
jak to zrobiłeś? ping ...
knocte
Jednym ze sposobów byłoby znalezienie otwartych sesji przy użyciu whoi zabijaniu procesów użytkownika.
Flatron
Jak zabić sesje ssh: unix.stackexchange.com/questions/127571/…
Tejas Kale
4

Natknąłem się na ssh_exchange_identification: read: Connection reset by peerproblem w skrypcie, który rozpoczyna 16 lub więcej sesji ssh w pętli. sshd najwyraźniej nie nadąża; dodanie krótkiego snu rozwiązało mój problem:

for i in $(seq 32)
do
    ssh -f root@$HOST "./test_server -p $(expr $BASE_PORT + $i)" > svr${i}.out
    # for > 8 connections, ssh has ssh_exchange_identification issues
    sleep 0.1
done
duanev
źródło
3

Albo mogłeś zrobić to, co zrobiłem zeszłej nocy i usunąłem / var / empty. Najwyraźniej ten katalog i jego uprawnienia są niezbędne do funkcjonowania sshd i nie będzie on ponownie katalogować po zrestartowaniu /etc/init.d/sshd, nie zrestartuje się i nic systemd nie powie ci dlaczego.

Znalazłem problem, uruchamiając sshd na pierwszym planie:

# /usr/sbin/sshd -Dd
  Missing privilege separation directory: /var/empty/sshd

Przebudowa katalogów rozwiązała problem w moim przypadku:

drwxr-xr-x. root root  /var/empty
drwx--x--x. root root  /var/empty/sshd

Uwaga dla programistów Linuksa: Krytycznie ważne rzeczy w /var/empty... naprawdę ???

crashulater
źródło
ls -ld /var/emptyls: cannot access '/var/empty': No such file or directory. Tak więc przynajmniej jedna dystrybucja całkowicie to zlikwidowała. Patrząc na /etc/init.d/sshdskrypt, wydaje się, że przynajmniej w Debianie katalog separacji uprawnień jest teraz /var/run/sshdi jest tworzony w czasie uruchamiania, jeśli jeszcze nie istnieje.
roaima
1

Wystąpił błąd ssh_exchange_identification: Connection closed by remote hostpodczas próby połączenia się z SSH: wykonałem przekierowanie portu zdalnego dla portu SSH 22 mojego komputera lokalnego, aby móc uzyskać do niego tymczasowy dostęp ze zdalnego serwera w Internecie.

W rzeczywistości błąd został wyświetlony tylko dlatego, że nie pamiętam, że wyłączyłeś usługę SSH na starcie, więc musiałem uruchomić usługę SSH na moim komputerze lokalnym: sudo service ssh start.

baptx
źródło
1
dziękuję, ratujesz mi życie.
Al Kasih
0

Najpierw pierwsza; telnet na adres IP hosta, aby sprawdzić, czy port 22 faktycznie nasłuchuje (otwarty) na tym hoście:

telnet x.x.x.x 22

(jeśli nie, możesz podłączyć kabel konsoli, aby się zalogować)

W moim przypadku nie działało i podłączyłem kabel konsoli, aby się zalogować. Po zalogowaniu odkryłem, że wszystkie 5 linii VTY było zajęte na tym hoście (routerze Cisco).

Wyczyściłem stare połączenia, które tam wisiały, aby zwolnić linie VTY, zadziałało. Dodałem polecenie „exec-timeout 15” pod wierszami VTY. Następnie wyjąłem kabel konsoli.

Lekcja:

Upewnij się, że ustawiłeś limit czasu 5-10 minut na wszystkich urządzeniach - (jeśli nie zostanie wykryta żadna aktywność).

Oumar
źródło
2
W takim przypadku pojawi się „odmowa połączenia”, jak sugeruje inna odpowiedź , a nie „Połączenie nawiązane”, a następnie „Resetowanie połączenia przez peer”
Jeff Schaller
1
Posiadanie dostępnego telnetu (nasłuchiwanie demona dla telnetu) jest dość poważną wadą bezpieczeństwa, wadą, która jest głównym powodem, dla którego ssh jest preferowaną zdalną konsolą.
Xalorous,
Użycie klienta Telnet do zbadania demona ssh na porcie 22 nie jest luką w zabezpieczeniach. Użycie klienta Telnet do połączenia się z demonem Telnet na porcie 23 jest luką w zabezpieczeniach.
Dan Anderson
0

Mój przypadek został przez pomyłkę ustawiony proxy proxy (który nie działa). Mam dokładnie to samo wyjście ssh -vvv i pusty dziennik sshd.

clarkttfu
źródło
0

Błąd ssh_exchange_identification: Connection closed by remote hostmoże wystąpić z nieznanych przyczyn. Kiedy korzystałem z kodu Visual Studio . Ten sam błąd wystąpił, gdy próbowałem pobrać ze zdalnego repozytorium za pomocą git pullpolecenia.

Właśnie zamknięte wbudowanego terminala i otworzył terminalu Ubuntu i pociągnął ponownie. I udało się

Mohammed Shareef C.
źródło
0

Od z CentOS Linux release 7.4.1708 (Core)z OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017tyłu połączenie nie filtrujące portów miałem:

ssh_exchange_identification: Połączenie zamknięte przez zdalny host

I okazało się, że moja Raspberry Pi była wyłączona!

Myślałem, że host, który nie jest włączony, zwróci błąd „Brak trasy do hosta”. Raspberry Pi stoi za moim routerem ISP, więc prawdopodobnie to on zamyka połączenie.

Następnie powtórzyłem eksperyment (próba połączenia z wyłączonym Raspberry Pi) z innego połączenia internetowego, również nie filtrując portów za pomocą Debian Stretch OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017i tym razem miałem oczekiwane:

Brak trasy do hosta

Gabriel Devillers
źródło