Problem SSH - Odczyt z gniazda nie powiódł się: Resetowanie połączenia przez partnera

23

Mogę SSH w jednym kierunku bez problemów:

DOBRZE:

ssh user@computerA

ale w drugą stronę:

ssh user@computerB

I dostać Read from socket failed: Connection reset by peer.

Nawet nie zaczynam wiedzieć, gdzie szukać rozwiązania tego problemu.

Czy ktoś ma jakieś wskazówki?

ssh

— boehj
źródło

Jaka jest twoja konfiguracja sieci? Czy którakolwiek maszyna znajduje się za zaporą ogniową / routerem?

— NorTicUs,

Oba zostały właśnie połączone ze sobą kablem Ethernet za pośrednictwem routera. W przeszłości mieli SSH w obu kierunkach.

— boehj

Czy sprawdziłeś, czy oba demony SSH działają? Coś w logach?

— NorTicUs,

Dobre i złe wiadomości: odpowiedziałem na własne pytanie. Napiszę to poniżej. Dziękuję za twoją pomoc.

— boehj

13

rozpocznij monitorowanie pliku dziennika serwera

tail -f /var/log/auth.log
dodaj -v, aby uzyskać pełne wyjście po stronie klienta

ssh user@computerB -v

Może to dać więcej szczegółów na temat przyczyny. jeśli na serwerze brakuje kluczy rsa i dsa, napraw je:

ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t dsa  -f /etc/ssh/ssh_host_dsa_key

— wąglik
źródło

To zadziałało dla mnie. Choć musiałem być korzeń uruchomić co następuje: ssh-keygen -t dsa -f / etc / ssh / ssh_host_dsa_key

— StarDust

Ponowne generowanie kluczy zdecydowanie działa. W moim przypadku zmieniał adres IP maszyny po zainstalowaniu openssh (i klucze generowane podczas instalacji).

— Alfishe,

Po wykonaniu tej czynności straciłem szansę na połączenie z moim serwerem. Musiałem poprosić o pomoc dostawcy hostingu. Wciąż czekam na odpowiedź. Centos 7 z cPanel.

— Tomas Gonzalez,

8

Ponownie zainstalowałem bity SSH, wykonując:

sudo apt-get --reinstall install openssh-server openssh-client

To naprawiło wszystkie moje problemy.

— boehj
źródło

8

To może być zbieg okoliczności. To, że problem przestał się pojawiać w momencie ponownej instalacji ssh, nie jest szczelną gwarancją przyczyny i skutku. Przy okazji, którą stronę ponownie zainstalowałeś? Lub obydwa? W każdym razie „to pytanie raczej nie pomoże przyszłym użytkownikom”.

— Kaz.

5

Metoda änthräX jest bardzo pomocna. Mi to pasuje!

Zasadniczo myślę, że po zainstalowaniu ssh potrzebne są pliki kluczy.

Jedyną wersją, którą zrobiłem, było użycie rsazamiast rsa1:

ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key 
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key

Ta zmodyfikowana metoda działała dla mnie.

— Alan_04
źródło

To był problem w moim przypadku. Pakiet serwera ssh z bieżącą wersją Ubuntu dla maszyny Utilite ARM zainstalowanej z objawem OP. Po uruchomieniu tych dwóch poleceń (które zrobiłem jako root), mogę w końcu ssh wejść. Dziękuję bardzo. +1

— James T Snell

1

To dlatego, że jakoś /etc/sshzmieniły się uprawnienia do plików w środku ... Więc zmień uprawnienia do plików, tak jak w przykładzie podanym poniżej:

posługiwać się:

chmod 644 ssh_config
chmod 600 moduli

i tak dalej...

Wreszcie uprawnienia do plików powinny wyglądać jak podane poniżej,

[root@hostname ssh]# ls -latr
total 172

-rw-r--r--.   1 root root   2047 Aug 12  2010 ssh_config
-rw-------.   1 root root 125811 Aug 12  2010 moduli
-rw-------.   1 root root    963 Mar  1 16:02 ssh_host_key
-rw-r--r--.   1 root root    627 Mar  1 16:02 ssh_host_key.pub
-rw-r--r--.   1 root root    382 Mar  1 16:02 ssh_host_rsa_key.pub
-rw-------.   1 root root   1675 Mar  1 16:02 ssh_host_rsa_key
-rw-r--r--.   1 root root    590 Mar  1 16:02 ssh_host_dsa_key.pub
-rw-------.   1 root root    668 Mar  1 16:02 ssh_host_dsa_key
-rw-------.   1 root root   3845 May  7 11:52 sshd_config

Po zmianie uprawnień spróbuj połączyć się ze szpachlą, powinno działać dobrze.

— Varun Joseph
źródło

1

Dlaczego Kit jest odpowiedni? Zastanów się, czy OP nie ma uprawnień do plików, zanim doradzi, że je zmieni.

— Clive van Hilten

Bardzo przepraszam, że opublikowałem odpowiedź w niewłaściwy sposób. Teraz o to chodzi, podczas instalacji aplikacji ktoś zmienił uprawnienia do tych plików na 777. Dowiedziałem się o tym podczas przechodzenia przez / var / log / messages (połączenie szeregowe z maszyna). Stąd zmieniłem uprawnienia i zgadnij co? potem wszystko działało dobrze.

— Varun Joseph

1

Mieliśmy podobny problem, ale pojawił się tylko podczas logowania z Ubuntu do Solaris. Upewnienie się, że wszystkie te linie są obecne /etc/ssh/ssh_config na hoście Ubuntu, rozwiązało problem (powinieneś znaleźć niektóre z tych linii już są obecne):

Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
HostKeyAlgorithms ssh-rsa,ssh-dss
MACs hmac-md5,hmac-sha1,hmac-ripemd160

W przypadku Xubuntu potrzebowałem tylko dwóch ostatnich.

— Philip Kearns
źródło

0

Ten komunikat może również wynikać z wielu prób ataku ssh. Jeśli widzisz ten komunikat w dziennikach, złośliwe źródło może próbować ssh do twojego komputera przy użyciu prób użycia hasła brute-force.

Aby spowolnić próby, zainstaluj pakiet „fail2ban”:

sudo apt-get install fail2ban

Ze strony wiki fail2ban :

Fail2ban skanuje pliki dziennika (np. / Var / log / apache / error_log) i blokuje adresy IP, które pokazują złośliwe znaki - zbyt wiele awarii haseł, szukanie exploitów itp. Ogólnie Fail2Ban jest następnie używany do aktualizacji reguł zapory ogniowej w celu odrzucenia adresów IP przez określony czas

— Liloulinx
źródło

1

Wyjaśnij swoją odpowiedź, podając więcej szczegółów na temat tego, dlaczego miałoby to działać

— DnrDevil,