połączenie ssh na przystanek „debug1: SSH2_MSG_KEXINIT wysłane”

Question

Zmieniłem ssh numer portu od 22 do 2222 poprzednie połączenie ustawienie domyślne ssh port 22 jest w porządku Mam zmapowali NAT na routerze poprawnie

Kiedy próbuję debugowania to

ssh -v -p2222 www.example.com 

otrzymuję ten błąd wiszące

debug1: SSH2_MSG_KEXINIT 

poniżej jest cały dziennik debugowania

bob@server:~$ ssh -v -p2222 www.example.com 
OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007 
debug1: Reading configuration data /etc/ssh/ssh_config 
debug1: Applying options for * 
debug1: Connecting to www.example.com [100.100.100.100] port 2222. 
debug1: Connection established. 
debug1: identity file /home/bob/.ssh/identity type -1 
debug1: identity file /home/bob/.ssh/id_rsa type -1 
debug1: identity file /home/bob/.ssh/id_dsa type -1 
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu1.2 
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu1.2 pat OpenSSH* 
debug1: Enabling compatibility mode for protocol 2.0 
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2 
debug1: SSH2_MSG_KEXINIT sent 
Connection closed by 100.100.100.100 

Podobnie jak w związku z tym uzyskać zamknięte użyłem gnome-terminal, szpachlówki, SecureCRT na maszynach para w sieci i poza nią jeszcze wszyscy się ten sam błąd

Answer 1

SSH2_MSG_KEXINIT nie jest błędem. Mówi tylko, że rozpoczyna proces wymiany klucza ssh.

Jeśli drugi koniec zamyka połączenie w tym miejscu, najwyraźniej nie podoba ci się z jakiegoś powodu :-) Czy masz dostęp do logów na serwerze, z którym się łączysz? To może zawierać informacje o tym, dlaczego połączenie jest gwałtownie zamykane. (tcpwrappers, na przykład)

Answer 2

Miałem ten sam problem, sshd wprawiło mnie w zakłopotanie, gdy zmieniłem port w sshd_config i zrestartowałem usługę sshd, kiedy w końcu spojrzałem na logi serwera (które wygląda na to, że nie możesz) , sshd narzekał na port już wykorzystywany, uzgodniono netstat, a ps pokazało kilka uruchomionych usług sshd. Zabiłem je i zacząłem ponownie tworzyć sshd i mogłem się połączyć. Przysięgam, że próbowałem ponownie uruchomić system, aby naprawić problem, ale chyba nie, ponieważ prawdopodobnie to naprawiłoby.

Krótko mówiąc, sshd, który powinien nasłuchiwać na porcie 2222, aby się uwierzytelnić, nie jest tym, który słucha, innym procesem jest sshd. Jeśli masz ten sam problem, co ja.

Answer 3

Miałem ten problem i rozwiązałem go, ustawiając MTU na docelowym routerze/zaporze sieciowej i na docelowym hoście tak samo jak źródłowy host (1500).

Answer 4

Po prostu przydarzyło mi się to na hoście XEN. Powieliłem tego hosta od innego i, jak to często bywa, usunąłem klucze hosta w/etc/ssh po wykonaniu tego, myśląc, że nowe zostaną wygenerowane później. Ale to się nigdy nie zdarzyło i sshd z radością uruchomił się bez kluczy hosta. Podczas próby ssh na tym hoście, po SSH2_MSG_KEXINIT odpadłby. Wszystko co musiałem zrobić, to utworzyć klucze hostów, które oparte na maszynie Debian jest robione w ten sposób:

dpkg-reconfigure openssh-server