Błąd SSH ssh_exchange_identification: read: Resetowanie połączenia przez peer

Próbuję uzyskać dostęp do ssh do serwera, ale otrzymałem komunikat „ ssh_exchange_identification: read: Connection reset by peer ”. Ten sam klient działa dobrze, gdy przenoszę komputer do domu, ale wyświetla błąd, gdy komputer jest w biurze pracy. Czy to możliwe, że niektóre ustawienia sieci LAN w sieci biurowej powodują problem? Próbowałem innych komputerów w sieci biurowej, ten sam problem.

Czy mogę zmienić ustawienia serwera, aby rozwiązać ten problem?

Klient i serwer z tym samym Debianem „Linux debian 3.16.0-4-amd64 # 1 SMP Debian 3.16.7-2 (2014-11-06) x86_64 GNU / Linux”

Po stronie klienta dziennik pokazuje:

OpenSSH_6.7p1 Debian-3, OpenSSL 1.0.1j 15 października 2014
debug1: odczyt danych konfiguracyjnych /home/client/.ssh/config
debug1: /home/client/.ssh/config wiersz 13: Stosowanie opcji dla navtk
debug1: odczyt danych konfiguracyjnych / etc / ssh / ssh_config
debug1: / etc / ssh / ssh_config wiersz 19: Stosowanie opcji dla *
debug1: nazwa hosta uległa zmianie; ponowne czytanie konfiguracji
debug1: odczyt danych konfiguracyjnych /home/client/.ssh/config
debug1: odczyt danych konfiguracyjnych / etc / ssh / ssh_config
debug1: / etc / ssh / ssh_config wiersz 19: Stosowanie opcji dla *
debug2: ssh_connect: needpriv 0
debug1: Łączenie z www.host.com [xx.xx.xx.xx] port xx.
debug1: Połączenie ustanowione.
debug1: plik tożsamości /home/client/.ssh/user typ 1
debug1: key_load_public: Brak takiego pliku lub katalogu
debug1: plik tożsamości /home/client/.ssh/user-cert typ -1
debug1: Włączanie trybu zgodności dla protokołu 2.0
debug1: Ciąg wersji lokalnej SSH-2.0-OpenSSH_6.7p1 Debian-3
ssh_exchange_identification: read: Resetowanie połączenia przez partnera

I zaloguj się po stronie serwera

Serwer nasłuchuje na :: porcie 443.
debug3: fd 5 nie jest O_NONBLOCK
debug1: Serwer nie rozwidla się podczas działania w trybie debugowania.
debug3: send_rexec_state: enter fd = 8 config len 735
debug3: ssh_msg_send: wpisz 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: gniazda inetd po skopiowaniu: 3, 3
debug1: getpeername failed. Punkt końcowy transportu nie jest połączony
debug1: get_remote_port nie powiodło się

„Resetowanie połączenia przez peer” oznacza, że ​​strumień TCP został nienormalnie zamknięty z drugiego końca. Myślę, że najbardziej prawdopodobnymi wyjaśnieniami są awarie procesu zdalnego serwera obsługującego połączenie lub też inne urządzenie sieciowe (takie jak zapora stanowa lub moduł równoważenia obciążenia) postanowiło zakłócać połączenie.

Musisz to debugować na zdalnym serwerze, jeśli możesz. sshdloguje się syslog, aw typowym systemie uniksowym wpisy dziennika będą znajdować się w jednym z plików w /var/logkatalogu. Jeśli masz szczęście, sshdbędziesz rejestrować coś za każdym razem, gdy zakończy sesję.

Jeśli masz dostęp do roota na serwerze, możesz uruchomić instancję debugowania sshd. Zostań rootem, a następnie uruchom:

/path/to/sshd -ddd -p 1022

Spowoduje to uruchomienie instancji serwera SSH, który nasłuchuje na porcie 1022, zaakceptuje jedno połączenie i wydrukuje informacje o debugowaniu na twoim terminalu. Uruchom klienta w zwykły sposób, z tym wyjątkiem, że jako port podaj port 1022:

ssh -p 1022 user@host

Mam nadzieję, że informacje debugowane przez serwer wyjaśnią, co się dzieje.

Edycja: Dane wyjściowe serwera wskazują, że serwer nie ulega awarii lub celowo nie zamyka połączenia TCP. Coś innego powoduje, że się zamyka. Przyjrzałbym się każdemu oprogramowaniu zabezpieczającemu zainstalowanemu na serwerze, które może monitorować sesje TCP, a także zapory ogniowe, usługi równoważenia obciążenia lub podobny sprzęt sieciowy, który może być częścią sieci lokalnej.

Mam ten sam problem. W tej chwili wygląda na to, że problem dotyczy mojego dostawcy usług internetowych. Spróbuj wykonać traceroute na swoim serwerze. Dla mnie to się nie udaje przed dotarciem do serwera.

Mój serwer jest współdzielonym serwerem hostingowym. Moja firma hostingowa powiedziała mi, że mają ten sam problem z innymi klientami korzystającymi z AT&T lub Comcast.

Mam nadzieję, że to pomoże, a przynajmniej uratuje cię przed spędzaniem nadmiernego czasu na innych możliwościach.

Jest tu za późno, ale może ktoś po prostu wskoczy w to, co może okazać się pomocne.

1. Uruchom ponownie (zatrzymaj i uruchom) serwer.
2. Dostęp do serwera przez ssh ponownie z publicznym IP. (Możesz przejść do następnego kroku, jeśli się powiedzie.)
3. Uruchom ponownie serwer WWW.

To wszystko, może być konieczne ponowne wskazanie domeny na publiczny adres IP.

Moje środowiska to AWS i NGINX.

„ssh_exchange_identification: read: Connection reset by peer” nastąpi również, gdy znajdziesz się na liście bloków (np. ponieważ zbyt często wpisałeś nieprawidłowe hasło). Zdarzyło mi się z moim Synology-NAS. Sprawdź, czy adres IP, z którego się łączysz, nie znajduje się na tej liście.

W przypadku synchronizacji zaznacz „Panel sterowania” / „Bezpieczeństwo” / „Konto”.

Może być wiele przyczyn, ale jedną z najbardziej prawdopodobnych przyczyn może być (w moim przypadku było), że ssh / port 22 nie jest dozwolony przez firewall .

Możesz zezwolić na połączenie ssh przez interfejs użytkownika (niektórzy dostawcy na to pozwalają) lub Jeśli masz inną metodę logowania (np. Digitalocean zapewnia przycisk konsoli), możesz uruchomić poniżej polecenia

sudo ufw allow ssh
sudo ufw allow 22