Ich habe die SSH-Portnummer von 22 auf 2222 geändert. Die zuvor eingerichtete Verbindung zum Standard-SSH-Port 22 ist in Ordnung. Ich habe das NAT auf dem Router richtig zugeordnet.
Wenn ich versuche, es zu debuggen
ssh -v -p2222 www.example.com
Ich bekomme diesen Fehler hängen
debug1: SSH2_MSG_KEXINIT
Unten finden Sie das gesamte Debugprotokoll
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
Genau wie diese Verbindung geschlossen wird, habe ich Gnome-Terminal, Putty, Securecrt auf einigen Maschinen innerhalb und außerhalb des Netzwerks verwendet, immer noch alle erhalten den gleichen Fehler
Antwort1
Mir ist das gerade auf einem XEN-Host passiert. Ich hatte diesen Host von einem anderen dupliziert und wie üblich die Hostschlüssel in /etc/ssh danach gelöscht, in der Annahme, dass später neue generiert würden. Aber das ist nie passiert und sshd startete problemlos ohne Hostschlüssel. Beim Versuch, per SSH auf diesen Host zuzugreifen, brach es nach SSH2_MSG_KEXINIT ab. Ich musste nur die Hostschlüssel erstellen, was auf Debian-basierten Maschinen folgendermaßen gemacht wird:
dpkg-reconfigure openssh-server
Antwort2
Ich hatte dieses Problem und habe es gelöst, indem ich die MTU am Zielrouter/an der Zielfirewall und im Zielhost auf den gleichen Wert wie auf dem Quellhost (1500) eingestellt habe.
Antwort3
Ich hatte das gleiche Problem. SSHD war verwirrt, als ich den Port in sshd_config änderte und den SSHD-Dienst neu startete. Als ich mir schließlich die Serverprotokolle ansah (was anscheinend nicht möglich ist), beschwerte sich SSHD, dass der Port bereits verwendet wurde. Netstat stimmte zu und ein PS zeigte mehrere Instanzen laufender SSHD-Dienste. Ich beendete diese und startete SSHD erneut und konnte eine Verbindung herstellen. Ich schwöre, ich habe versucht, das Problem durch einen Neustart zu beheben, aber ich schätze, das habe ich nicht getan, denn das hätte es wahrscheinlich behoben.
Kurz gesagt, der SSHD, der auf Port 2222 lauschen sollte, um Sie zu authentifizieren, ist nicht derjenige, der tatsächlich lauscht, sondern ein anderer SSHD-Prozess. Wenn Sie das gleiche Problem haben wie ich.
Antwort4
SSH2_MSG_KEXINIT ist kein Fehler. Es zeigt Ihnen nur an, dass der SSH-Schlüsselaustauschprozess beginnt.
Wenn das andere Ende die Verbindung an diesem Punkt schließt, dann sind Sie ihm aus irgendeinem Grund offenbar nicht sympathisch :-) Protokolle der Remote-Seite enthalten möglicherweise Informationen darüber, warum die Verbindung abrupt beendet wird (z. B. TCPWrapper).