ssh_exchange_identification: read: Resetowanie połączenia przez partnera

105

Korzystam z systemu OS X i próbuję ssh na serwerze Ubuntu 12.04. Byłem w stanie SSH do - aż nagle rzeczy przestały działać. Czytałem online, aby użyć -vdo debugowania tego. Dane wyjściowe pokazano poniżej. Jeśli ssh w innym polu, a następnie ssh z tego pola na serwer, mogę się zalogować. Nie mam pojęcia, jak rozwiązać ten problem, ale chciałbym się nauczyć.

$ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer

Do tej pory (za radą forów dyskusyjnych) szukałem pliku odmowy hosta - ale takiego pliku nie ma na moim komputerze.

$ cat /etc/hosts.deny 
cat: /etc/hosts.deny: No such file or directory

Mam dostęp administratora na komputerze klienta, ale nie na serwerze.

ssh

— bernie2436
źródło

Zalecałbym rozpoczęcie sshdnasłuchiwania na alternatywnym porcie z pełnym wyjściem i dostarczenie wyjścia przy próbie połączenia się z nim. $(which sshd) -d -p 23. Jeśli nie masz takiej możliwości, masz dość ograniczone możliwości. Najlepiej jest zdobyć kogoś, kto ma uprawnienia administratora na serwerze.

— Patrick

Czy to możliwe, że administrator na serwerze ograniczył dostęp z jakiegoś powodu? W każdym razie mogę skontaktować się z tą osobą.

— mdpc

12

Plik hosts.deny i hosts.allow należy sprawdzić na serwerze , a nie na kliencie. Ponadto należy sprawdzić dzienniki systemowe na serwerze . Jeśli nie masz do nich dostępu, możesz skontaktować się z administratorem serwera, aby się przyjrzeć.

— ckujau

znalazłeś rozwiązanie? jaki był problem?

— MeV,

2

Była lista hosts.deny, która została wypełniona przez administratora automatycznym skryptem. Ponieważ w pewnym momencie zapomniałem hasła, miałem kilka nieudanych prób zalogowania się, kiedy to moje IP zostało umieszczone na liście hosts.deny. Tyle o wydajności nadgorliwego bezpieczeństwa.

— K.-Michael Aye,

23

Nagła zmiana może być wynikiem zmiany pliku konfiguracyjnego w konfiguracji serwerów sshd, ale użytkownik wskazuje, że nie można tego sprawdzić ani zmienić bez uprawnień administratora. Możesz nadal spróbować wykonać następujące czynności, jeśli nie uda się dotrzeć do administratorów serwera (na czas).

Twój dziennik wskazuje tylko ciąg wersji lokalnej, powinieneś sprawdzić wersje sshddziałające na serwerze i komputerze pośrednim.

Jeśli te wersje różnią się (zwłaszcza pomiędzy lokalnym komputerem a serwerem i mniej pośredniego między urządzeniem a serwerem) nie mogą być pewne negocjacje niezgodność, to działo się przed w ssh. Rozwiązaniem było skracanie szyfrów, wpisów HostKeyAlgorytmów i / lub adresów MAC, w wierszu poleceń ( ssh -c aes256-ctritp.) Lub w twoim /etc/ssh/ssh_config.

Powinieneś poszukać informacji o debugowaniu (od połączenia przez serwer pośredni z serwerem) w celu znalezienia odpowiednich wartości jako argumentu dla wiersza poleceń -c/ Ciphers, -o HostKeyAlgorithms/ HostKeyAlgorithmsi -m/ MACs. Zmiany w ssh_config.

Od dawna nie miałem tego problemu, ale IIRC wystarczyło, aby ręcznie wymusić ustawienie Ciphers i HostKeyAl algorytmów, po czym mogłem zaktualizować sshdwersję serwera i problem zniknął.

— Anthon
źródło

3

W moim przypadku sshdpakiet serwera został zaktualizowany do nowszej wersji i spowodował niezgodność z moją bieżącą sshkonfiguracją klienta, jak powiedziałeś. Usunięcie moich starych sshplików konfiguracyjnych załatwiło sprawę. To powinna być zaakceptowana odpowiedź.

— chakrit

2

@chakrit jak wyczyściłeś swoje stare pliki konfiguracyjne ssh?

— Jonathan

@Jonathan W tym celu zamontowałem dysk odzyskiwania.

— chakrit

16

Być może zostałeś zbanowany przez fail2banlub denyhosts. W takim przypadku (a także w celu sprawdzenia), jeśli nie chcesz zawracać sobie głowy pomocą dostawcy serwera, musisz zalogować się do swojego serwera z innego adresu IP: np. Innego serwera, połączenia domowego znajomego lub hotspot wifi lub używanie SSH z TOR.

Po zalogowaniu sprawdź, czy Twój adres IP rzeczywiście pojawia się w /etc/hosts.deny(po stronie serwera). Jeśli tak, to fail2banlub denyhostsmusi być sprawcą.

Zobacz odpowiedzi na to pytanie, aby dowiedzieć się, jak zapobiec denyhostsciągłemu blokowaniu adresu. Aby fail2banznaleźć swój adres IP iptables -L --line-numberi odblokować go za pomocą iptables -D <chain> <chain number>, sprawdź szczegółowe informacje na temat howtoforge .

Możesz dodać swój adres IP fail2bani denyhostsbiałe listy (odpowiednio /etc/fail2ban/jail.conf, wiersz ignoreipi /var/lib/denyhosts/allowed-hostsutwórz go, jeśli to konieczne (ale uważaj, że ścieżka może być inna w Twojej dystrybucji)), aby zapobiec ponownemu wystąpieniu problemu.

— Skippy le Grand Gourou
źródło

9

Na serwerze hosta usuń plik ssh pub.key znajdujący się tutaj: ~/.ssh/authorized_keysna komputerze Mac. Następnie tail -f /var/log/auth.logpodczas otwierania innego terminala i spróbuj ponownie ssh ssh -v me@server. Jeśli pojawi się monit o hasło, oznacza to, że wystąpił problem z kluczem ssh. Jeśli nadal widzisz odpowiedź „ssh_exchange_identification: read: Connection reset by peer”, powinieneś być w stanie zidentyfikować problem na podstawie wpisu dziennika w pliku „/var/log/auth.log” po nieudanej próbie zalogować się.

Jeśli nadal nie możesz się połączyć, opublikuj tutaj wpis z pliku auth, a ja poprawię odpowiedź.

— diabelnie
źródło

W niektórych przypadkach nie trzeba usuwać klucza SSH. Przejdź bezpośrednio do tail -f /var/log/auth.log i sprawdź ostatnie próby.

— Jack Robson

6

Może się to zdarzyć, jeśli masz wiele komputerów w sieci o tym samym adresie MAC (na przykład, jeśli wykonasz kopię maszyny wirtualnej i zapomnisz zmienić MAC).

— elCapitano
źródło

4

Otrzymywałem to z powodu serwerów nazw mojego ISP w /etc/resolv.conf. Te serwery nazw są często przeciążone, a jeśli odwrotne wyszukiwanie DNS nie powiedzie sshdsię, połączenie zostanie przerwane. Rozwiązałem problem, używając bardziej niezawodnych serwerów nazw, np 8.8.8.8.

— njahnke
źródło

4

Miałem ten sam problem. Z powodzeniem otworzę sesję ssh, ale po pewnym czasie zresetuje się. Gdy próbowałem od razu uzyskać wzmocnienie, otrzymałem komunikat o błędzie „Odmowa połączenia”. kiedy debugowałem sesję, dostałem ten komunikat w momencie resetowania połączenia

debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: channel 0: free: client-session, nchannels 1                             
debug3: channel 0: status: The following connections are open:                   
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)                              

debug3: channel 0: close_fds r 4 w 5 e 6 c -1                                    
Read from remote host 10.x.y.z: Connection reset by peer                    
Connection to 10.x.y.z closed.                                              
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds       
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1                      
debug1: Exit status -1

W tym momencie zdałem sobie sprawę, że w sieci wystąpił konflikt adresów IP. Zmieniłem adres na inny i problem został rozwiązany

— David
źródło

2

Przegłosuj, co jest nie tak z odpowiedzią? Nadal może to być uzasadniony przypadek, aby sprawdzić, kiedy przeglądasz listę, ale może nie jest to powszechny wśród innych.

— Pysis

@Pysis: Poprawna, pozytywna odpowiedź

— Daniel

3

Twój dziennik oznacza, że po stronie serwera zrywa połączenie. Aby znaleźć przyczynę, powinieneś sprawdzić dzienniki po stronie serwera, powinny one wskazywać powód rozłączenia. Prawie zawsze powinieneś być w stanie znaleźć dzienniki w / var / log / messages

Mogłem zgadywać, że gdy połączenie zostało przerwane tuż po wysłaniu przez klienta numeru wersji, serwer w jakiś sposób grozi klientowi jako niezgodny.

— gena2x
źródło

3

Miałem ten sam problem, ale okazało się, że przyczyna była inna: korzystałem z niewłaściwego portu.

W nowszych wersjach sshpodany błąd to Connection refusedlub Bad port.

W starszych wersjach podany jest błąd ssh_exchange_identification: read: Connection reset by peer

Kiedy pojawi się taki błąd, sprawdź, czy port jest poprawny.

— Mugoma J. Okomba
źródło

1

Wiem, że to pytanie jest stare, ale chciałem podzielić się niektórymi wnioskami. Sprawdź, czy /var/empty/sshdna serwerze ma odpowiednią własność i uprawnienia.

Mieliśmy skrypt szefa kuchni, który został zmodyfikowany, aby zaktualizować niektóre uprawnienia do katalogu, ale przypadkowo zaktualizowałem katalog poniżej zamierzonego celu, zmieniając własność / var na użytkownika / grupę aplikacji i zmieniając uprawnienia na 775.

— Andrew Boerema
źródło

1

Ponieważ nie zostało to wyraźnie wymienione w odpowiedzi, ten błąd może pojawić się również wtedy, gdy zapora sieciowa między tobą a serwerem zdecyduje się zablokować połączenie. Zapora mogła zdecydować, że istnieje „zbyt wiele” połączeń z adresu IP systemu OS X i zaczęła go blokować. Nie było jeszcze „zbyt wielu” połączeń z drugiego systemu, więc było to dozwolone.

Ostatnia wiadomość otrzymana z serwera to taka, która pojawia się jeszcze przed rozpoczęciem jakichkolwiek prób uwierzytelnienia, co wyklucza dużą klasę możliwości związanych z Twoim kontem, kluczem lub hasłem.

Przykładami takich zasad brutalnej siły z losowego próbkowania dostawców są:

— Jeff Schaller
źródło