
Dieses Problem tritt bei mir immer wieder auf einem meiner MySQL-Cluster-Server auf. Eigentlich passiert es immer auf jedem beliebigen MySQL-Server dieses Clusters, und zwar in vielen Ländern, in denen wir dieselbe Konfiguration haben.
Ich habe diesen „dbX-Knoten“, den ich anpingen kann:
$ ping 192.0.2.4
PING 192.0.2.4 (192.0.2.4) 56(84) bytes of data.
64 bytes from 192.0.2.4: icmp_seq=1 ttl=61 time=1.92 ms
64 bytes from 192.0.2.4: icmp_seq=2 ttl=61 time=2.46 ms
Ich kann über Telnet TCP Port 22:
telnet 192.0.2.4 22
Trying 192.0.2.4 ...
Connected to 192.0.2.4.
Escape character is '^]'.
Und sofort geschlossen:
Connection closed by foreign host.
Und offensichtlich funktioniert SSH selbst nicht:
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug3: Not a RSA1 key file /home/user/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host
Ich kann auch per Telnet auf den MySQL-Port zugreifen:
# telnet db5 3306
Trying 192.0.2.4...
Connected to db5 (192.0.2.4).
Escape character is '^]'.
Kann aber keine Verbindung dazu herstellen:
# mysql -h db5 -uroot
Dieser Server ist ein ProLiant DL360p Gen8 mit RHEL 5.5
Wenn ich iLO zum Verbinden und Neustarten des SSH-Daemons verwende, wird keine Konsolen-Eingabeaufforderung angezeigt, sondern nur ein kleines graues Ding in der Ecke ...
Ich muss den Server, der mit diesem Problem konfrontiert ist, ständig neu starten.
Ich brauche Hilfe, um dieses Problem zu lösen. Ich habe alles versucht. Haben Sie schon einmal etwas Ähnliches erlebt?
Antwort1
Für SSH sieht es so aus, als ob Sie einen Putty-Schlüssel verwenden. SSH kann keinen Putty-Schlüssel verwenden, es sei denn, er wird in das OpenSSH-Format exportiert. Es sieht so aus, als ob die Datei manuell bearbeitet wurde. Stellen Sie den privaten Schlüssel nach Möglichkeit aus einer Sicherung wieder her oder versuchen Sie, die verwendeten Schlüssel erneut zu generieren, oder erstellen Sie einen neuen Schlüssel und vergleichen Sie die beiden, um sicherzustellen, dass die Formatierung des von Ihnen verwendeten Schlüssels nicht geändert wurde.
Dass Telnet sofort beendet wird, ist zu erwarten, da SSH nach SSH-Verbindungen und nicht nach Telnet-Verbindungen sucht.
Sobald Sie die Hauptprobleme behoben haben, sollten Sie in der Lage sein, sich per SSH mit der Box zu verbinden.
Was die MySQL-Anmeldung betrifft, ist die Standardanmeldung für Root normalerweise auf 127.0.0.1 und den lokalen Host beschränkt. Wenn Sie also nicht bestimmte Hosts (IhrenHost.Domäne) oder % (% ist übrigens keine gute Idee) zugelassen haben, können Sie keine Verbindung herstellen, es sei denn, Sie verwenden einen SSH-Tunnel, damit Sie eine lokale Verbindung herstellen können. Außerdem mysql -h db5 -uroot
versucht Ihr aktueller Befehl, eine Verbindung zu Root ohne Kennwort herzustellen. Versuchen Sie es stattdessen mit , mysql -h db5 -u root -p
das Sie zur Eingabe des Kennworts auffordert.
Antwort2
Gluzzer,
Es kann ein bisschen dauern.
Überprüfen Sie Ihre Konfigurationsdateien und stellen Sie sicher, dass Sie über das Netzwerk, von dem aus Sie eine Verbindung herstellen, auf das Gerät zugreifen dürfen.
Stellen Sie sicher, dass diese Server und die Netzwerke, mit denen sie verbunden sind, Sie anpingen können. Wenn Sie im Netzwerk ein Einweg-Routing haben, schlägt das bei Ihren Zugriffsversuchen fehl. Einige Netzwerkadministratoren blockieren ICMP-Ping-Anfragen und Firewall-/Zugriffslistenregeln können Sie daran hindern, auf Ihre Geräte zuzugreifen, es sei denn, Sie befinden sich im selben Subnetz wie sie.
Neuere Linux-Serverinstallationen mit iptables / ipforwarding / ipchains sperren standardmäßig alles. Sie müssen jeden benötigten Port oder Socket manuell öffnen. Einige Installationsskripte kümmern sich darum. Andere schlagen fehl und Sie müssen sie mit manuellen Linux-Befehlen öffnen.
Zweischneidiges Schwert … blockiert durch die Anwendungskonfigurationen/den lokalen Computer oder durch Ihr eigenes Netzwerkteam.
Hoffe, das hilft ein bisschen. Prost ...