SSH nie działa z jednego określonego komputera

Mogę łączyć się z każdego innego komputera w sieci LAN, a także zewnętrznie. Łączy się dobrze z innymi maszynami z SSHD. Kiedy próbuję ssh z gadatliwością, otrzymuję następujący odczyt:

$ ssh -vvv 192.168.1.9
OpenSSH_6.2p2, OpenSSL 1.0.1e 11 Feb 2013
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.9 [192.168.1.9] port 22.
debug1: Connection established.
debug1: identity file /home/Steven/.ssh/id_rsa type -1
debug1: identity file /home/Steven/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/Steven/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /home/Steven/.ssh/id_dsa type 2
debug1: identity file /home/Steven/.ssh/id_dsa-cert type -1
debug1: identity file /home/Steven/.ssh/id_ecdsa type -1
debug1: identity file /home/Steven/.ssh/id_ecdsa-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

Masz pojęcie, co mogłem pomylić? Nie przypominam sobie zmiany w plikach konfiguracyjnych SSH, tylko dodawanie niektórych użytkowników do grup w celu eksperymentowania z uprawnieniami. Nawet gdy próbuję nie podawać konta (jak wyżej), nadal zawiesza się on na „Ciąg wersji lokalnej SSH-2.0-OpenSSH_6.2” przez minutę, zanim poda ostatni błąd. Korzystam z Ubuntu Server 12.04 x86, za co jest wart.

Ostatecznie oznacza to, że serwer SSH na drugim końcu uległ awarii lub w jakiś sposób nie działa. Nadal nasłuchuje na gnieździe, ale nie jest w stanie wykonać kryptograficznego uścisku dłoni.

Jedynym rozwiązaniem jest ponowne uruchomienie procesu po stronie zdalnej.

Miałem ten sam problem, ale znalazłem, że mój adres IP został dodany do pliku etc / hosts.deny.

Rozwiązałem ten problem, logując się na innym serwerze VPS, a następnie podłączając ssh do zablokowanego VPS i usunąłem mój (domowy statyczny) adres IP z pliku hosts.deny.

Moją pierwszą próbą było znalezienie „ ssh_exchange_identification: read: Connection reset by peer” i sprawdzenie krzyżowe z kodem źródłowym, ale niestety nie znalazłem żadnego. Tak więc kilkoma metodami próbowałem replikować ten sam problem po mojej stronie, ale nie mogłem stworzyć tego samego problemu po mojej stronie, jak widać poniżej.

Z sshd_config rootem DenyUsers

Dziennik po stronie klienta

Odmowa dostępu, spróbuj ponownie

Dziennik po stronie serwera

2 lipca 02:47:32 serwer sshd [27118]: root użytkownika z CLIENT_IP nie jest dozwolony, ponieważ wymieniony w DenyUsers

Z hosts.deny

sshd: CLIENT_IP

Dziennik debugowania po stronie klienta:

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

Dziennik po stronie serwera

2 lipca 02:46:28 serwer sshd [27100]: odmówiono połączenia z CLIENT_IP (CLIENT_IP)

Z PAM odmawiaj

Dziennik po stronie klienta:

Odmowa dostępu (klucz publiczny, interaktywny z klawiaturą).

Dziennik po stronie serwera:

PAM-listfile: Odmówiono użytkownikowi xyz dla usługi ssh

Z kontem blokady

Dziennik po stronie klienta:

debug2: wysłaliśmy pakiet hasła, poczekaj na odpowiedź debug1: Uwierzytelnienia, które można kontynuować: publickey, gssapi-with-mic, hasło Odmowa dostępu, spróbuj ponownie.

Dziennik po stronie serwera:

2 lipca 02:57:16 serwer sshd [27303]: pam_unix (sshd: auth): błąd uwierzytelnienia; logname = identyfikator użytkownika = 0 euid = 0 tty = ssh ruser = rhost = KLIENT_IP użytkownik = test użytkownika 2 lipca 02:57:17 serwer sshd [27303]: Nieudane hasło do testu użytkownika z portu CLIENT_IP 39431 ssh2 lipca 2 02:57:35 serwer sshd [27303]: Nieudane hasło do testu użytkownika z portu 39431 ssh2 CLIENT_IP

Potem po przeprowadzeniu wyszukiwania w Google wydaje się, że jest to problem, ponieważ:

• Duplikat adresu IP w sieci
• Może to być błąd.

Może się to zdarzyć, jeśli routing między dwoma komputerami jest inny. Warto przyjrzeć się zarówno konfiguracjom routingu dwóch punktów końcowych, jak i wszelkim zaporom ogniowym, przez które przechodzą pakiety.

Spróbuj: ssh -2 name@iplubssh -2 -l name ip