Ich versuche, mit dem folgenden Befehl über SSH eine Verbindung zu einem Linux-Server herzustellen:
ssh [email protected] -p 22
Ich kann jedoch keine Verbindung herstellen. Es kam nur die Meldung: dispatch_protocol_error: type 51 seq 5. Der SSH-Befehl bleibt etwa ein bis zwei Minuten hängen, bis er mit den folgenden Meldungen geschlossen wird:
Connection to ip.of.server.com closed by remote host.
Connection to ip.of.server.com closed.
Eine Suche in Google nach der Meldung dispatch_protocol_error hat nichts Relevantes zu diesem spezifischen Dispatch-Protokollfehler ergeben. Es handelte sich hauptsächlich um Fragen zu anderen Dispatch-Protokollfehlern (mit anderen Werten für Typ und Sequenz) und in keinem dieser Fälle gab es eine Erklärung dazu, was diese Fehlermeldung bedeutet.
Das einzig mehr oder weniger Interessante istdiese OpenSSH-FAQ, wo eine der Fragen einen „Dispatch-Protokollfehler: Typ 20“ betrifft, der auftritt, weil „ältere Versionen von OpenSSH keine Sitzungsneuverschlüsselung unterstützten“. Es wird mir vorgeschlagen, RekeyIntervalSeconds 0dies zu „ssh2_config oder sshd2_config von SSH 2.3“ hinzuzufügen. Um zu sehen, was passiert, habe ich versucht, dies zu meiner (Client-)ssh_config hinzuzufügen (ich habe keine ssh2_config-Datei), aber das hat nicht geholfen (tatsächlich war es eine „falsche Konfigurationsoption“).
Ich habe versucht, eine Verbindung ohne Port ( ) herzustellen, und das Ergebnis war das gleiche. Ich habe auch versucht,ssh [email protected]Entfernen Sie den Host aus der Liste der bekannten Hostsdurch die Verwendung von ssh-keygen -R hostname, in der Annahme, dass es ein Problem mit dem aktuellen RSA-Schlüsselfingerabdruck gab. Dies erlaubte mir jedoch keine Verbindung und es wurde die gleiche Fehlermeldung angezeigt.
Ich verwende Ubuntu 16.04 und der Server ist CentOS 6.8. Meine (Client-)Version von SSH ist die Version 7.2 (vondiese Antwort: ssh -v localhost):
OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g
Ich vermute – und mein Chef stimmt mir zu – dass es sich um ein Serverproblem handelt und ich es daher nicht allein durch die Arbeit an meinem Computer lösen kann.
Meine Frage ist also:was diese Fehlermeldung bedeutet und wie man sie behebt?
P.S.: Ich bin kein SSH-Experte, daher habe ich wahrscheinlich sehr dumme Dinge getan und etwas Wesentliches zur Lösung dieses Problems übersehen.
BEARBEITEN:Ich führe das SSH mit der Option -v (verbose) aus. Demnach konnte ich mich verbinden und authentifizieren ( debug1: Authentication succeeded (none).). Nach dieser Meldung folgen die folgenden Meldungen, darunter auch mein Fehler. Das vollständige Protokoll folgt unten:
OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ip.of.server.com [ip.of.server.com] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: Authenticating to ip.of.server.com:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: [email protected] compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: [email protected] compression: none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<3072<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:server_host_key_ssh_rsa_is_here
debug1: Host 'ip.of.server.com' is known and matches the RSA host key.
debug1: Found key in /home/myuser/.ssh/known_hosts:6
debug1: rekey after 3249842342 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 3249842342 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentication succeeded (none).
Authenticated to ip.of.server.com ([ip.of.server.com]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
dispatch_protocol_error: type 51 seq 5
debug1: Received SSH2_MSG_UNIMPLEMENTED for 6
debug1: Received SSH2_MSG_UNIMPLEMENTED for 7
debug1: Received SSH2_MSG_UNIMPLEMENTED for 9
debug1: Received SSH2_MSG_UNIMPLEMENTED for 10
debug1: Received SSH2_MSG_UNIMPLEMENTED for 11
debug1: Received SSH2_MSG_UNIMPLEMENTED for 12
... (there are lots of this SSH2_MSG_UNIMPLEMENTED message)
debug1: Received SSH2_MSG_UNIMPLEMENTED for 60
debug1: Received SSH2_MSG_UNIMPLEMENTED for 61
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 1 clearing O_NONBLOCK
debug1: channel 0: free: client-session, nchannels 1
Connection to ip.of.server.com closed by remote host.
Connection to ip.of.server.com closed.
Transferred: sent ..., received ... bytes, in ... seconds
Bytes per second: sent ..., received ...
debug1: Exit status -1
Über die Serverseite: Suche im sshd-Log für CentOS ( /var/log/secure, wiediese Antwortzeigt), sind die einzigen relevanten Ergebnisse diese Wiederholung eines ähnlichen Fehlers:
Jan 5 14:38:44 myserverside sshd[1234]: dispatch_protocol_error: type 90 seq 6
Jan 5 14:38:44 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 7
Jan 5 14:38:46 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 9
Jan 5 14:38:48 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 10
Jan 5 14:38:50 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 11
Jan 5 14:38:52 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 12
...
Jan 5 14:40:31 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 60
Jan 5 14:40:33 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 61
Die anderen Einträge vor und nach diesem (mit anderen IDs) stammen nicht von diesem speziellen Versuch (sie stammen von meiner erfolgreichen PuTTY-Verbindung, wie ich an den Zeitdaten erkennen konnte). Es ist zu beachten, dass die Zahlen in diesen Fehlermeldungen dieselben sind, die ich auf der Clientseite erhalten habe.
Der Versuch mit dem Flag -M ( ) führte zum selben Fehler.ssh -M [email protected]
Seltsamerweise konnte ich mit einem Client mit einer älteren Version von Ubuntu (Ubuntu 12.04) eine Verbindung herstellen. Es kann also eine Versionsinkompatibilität sein (der Server ist zu alt und/oder der Client ist zu neu) - vielleicht ein aktuelles Update von SSH, da ich vor etwa einem Monat mit dem Ubuntu 16.04-Computer eine Verbindung herstellen konnte, oder vielleicht ein Konfigurationsproblem.
P.S.: Ich konnte mich erfolgreich über PuTTY (Ubuntu-Version) verbinden. Das Problem trat also nur beim Verbindungsversuch über SSH auf.