Zugriff auf 1und1-Fremde Datenbank

[Manuel Strunck]

Hallo!

Ich habe folgende konfiguration:
1. Webspace bei 1und1 (Business 5.0) mit MySQL5.0
2. Auf einem Root-Server (nicht bei 1und1) befindet sich ebenfalls eine MySQL5.0 Datenbank

Von einem Testsystem (lokaler Rechner) aus ist es kein Problem mehrere Datenbanken incl. der des Root-Servers zu konnektieren.

Sobald ich aber auf dem Livesystem (1und1-Webhosting) teste bekomme ich keine Verbindung zur Datenbank auf dem Root-Server. Es werden dummerweise auch keine Fehlermeldungen ausgespuckt.
Blockt 1und1 dort den Zugriff und wisst ihr mehr?

[Manuel B.]

Ich grüsse den Cosmos,

Blockt 1und1 dort den Zugriff und wisst ihr mehr?

Durchaus möglich. 1&1 schränkt den Beutzer schon von Anfang an massiv ein. Einer der Gründe, warum ich nie mehr dort Hosten würde.

Wie das mit deinem Server ist, kann dir vermutlich zu 100% nur der Support sagen. Gib uns aber bescheid, was rausgekommen ist, nur rein Interessehalber ;)

Möge das "Self" mit euch sein

[Tom]

Hello,

Blockt 1und1 dort den Zugriff und wisst ihr mehr?

Eigentlich nicht.
hast Du auch alle Fehlermeldungen eingeschaltet?

error_reporting E_ALL
display_errors  1

Normalerweise kassiert man eine Warnung beim Connect-Vesuch, wenn dieser schiefgeht.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Manuel Strunck]

Hi!

Der Support sagte, es sei durch die FW geblockt.

Danke wegen deines Hinweises, ich dachte ich hätte schon alle Fehler angezeigt bekommen.

Meldung:
Warning: mysql_connect() [function.mysql-connect]: Client does not support authentication protocol requested by server; consider upgrading MySQL client in...

So long

[Tom]

Hello,

Der Support sagte, es sei durch die FW geblockt.

Danke wegen deines Hinweises, ich dachte ich hätte schon alle Fehler angezeigt bekommen.

Meldung:
Warning: mysql_connect() [function.mysql-connect]: Client does not support authentication protocol requested by server; consider upgrading MySQL client in...

Da passen MySQÖ-Version und API nicht zusammen.
Welche PHP-Version wird tatsächlich benutzt?
Welche MySQL-Version wird tatsächlich benutzt?

1&1 hat php4  (assoziiert mit *.php)
        php5  (assoziiert mit *.php5)

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Manuel Strunck]

Hi!

Das mit den PHP versionen war mir gar nicht bewusst. Ich habe *.php dateien und somit Version 4.4.4.
Die externe Datenbank ist in der Version "4.1.10a-Max" vorhanden.

[Tom]

Hello,

Das mit den PHP versionen war mir gar nicht bewusst. Ich habe *.php dateien und somit Version 4.4.4.
Die externe Datenbank ist in der Version "4.1.10a-Max" vorhanden.

Und wenn Du nun zum Test die Datei mit dem Connect mit *.php5 benennst, hast Du dann Erfolg damit?

Ich habe jetzt nicht geschaut, ab wann das verschlüsselte Verbindungsverfahren mit MySQL benutzt wird. PHP 4 kann es jedenfalls nicht. Ab welcher MySQL-Version ist das notwendig? Wer weiß es auswendig?

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Ich habe jetzt nicht geschaut, ab wann das verschlüsselte Verbindungsverfahren mit MySQL benutzt wird. PHP 4 kann es jedenfalls nicht. Ab welcher MySQL-Version ist das notwendig? Wer weiß es auswendig?

Deine Aussage ist fehlerhaft.

Die dargestellte Fehlermeldung deutet eindeutig auf Inkompatibilitäten der verwendeten MySQL-Client-Bibliothek mit dem MySQL-Server hin. Siehe dazu auch http://dev.mysql.com/doc/refman/5.0/en/old-client.html.

Diese Inkompatibilität ist, weil eben der MySQL-Client von PHP verwendet wird, einkompiliert. Der Wechsel von PHP 4 auf 5 würde nur helfen, wenn das den Client ändert. Das ist aber zum Glück nicht die einzige Abhilfe, die man treffen kann.

Andererseits wundert es mich schon, dass 1&1 noch den alten 4.0-oder-älter-Client benutzen soll, wo doch die angebotenen Datenbanken alle 4.1 und neuer sind.

- Sven Rautenberg

[Tom]

Hello,

Deine Aussage ist fehlerhaft.

Glaub ich nicht. :-)

Ich hatte eine Frage gestellt. Seit wann verwendet MySQL Verschlüsselung und erfordert daher einen neuen Client?

Das man mittels einfacher Verwendung von PHP5 (mit dem neuen Client) anstelle von PHP4 (mit dem alten Client) das Problem ohne Neukompilation vom Tisch bekommt bei 1&1-Accounts, war die für den OP wesentliche Aussage. Manuel wird kaum Zugriff auf die Konfiguration der PHP-Version bei 1&1 haben.

Selbstverständlich kann man auch bei PHP4 den Client für MySQL austauschen. Das erfordert aber einigen Aufwand und außerdem geeigneten Zugriff auf den Server.

Du könntest die notwendigen Schritte allerdings gerne mal hier darlegen.
Dafür wäre ich Dir dankbar. Der Thread würde dann bestimmt oft gelesen werden.

Allerdings entgeht mir momentan der Grund dafür, warum man dann nicht gleich von PHP 4.x auf PHP 5.1 ff updaten sollte. Gibt es noch eine Distribution von PHP 5.1 ff, die den alten MySQL-Client verwendet?

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Deine Aussage ist fehlerhaft.

Glaub ich nicht. :-)

Ich hatte eine Frage gestellt. Seit wann verwendet MySQL Verschlüsselung und erfordert daher einen neuen Client?

Seit es Accounts in MySQL gibt.

Die Passwörter werden mit der PASSWORD()-Funktion verschlüsselt in der Usertabelle der "mysql"-Datenbank abgelegt. Diese Funktion hat sich verändert, erzeugt jetzt längere Hashwerte. Und an der Stringlänge erkennt MySQL, welches Verfahren verwendet wurde.

Offensichtlich ist auch der MySQL-Client für das Hashen des Passwortes mit verantwortlich - weshalb nicht nur die Serverversion, sondern auch die Version der Client-Bibliothek wichtig ist, da alte Clients nichts von der neuen Hashmethode wissen.

Die Fehlermeldung ist da ziemlich eindeutig. Mag sein, dass noch andere Probleme dahinterstecken können, aber da nicht bekannt ist, ob und wie 1&1 seine Server betreibt (die verlinkte Seite gibt zahlreiche Hinweise, wie das alte Verfahren beizubehalten ist), ist die offensichtliche Fehlermeldung eben zuallererst der Ansatzpunkt.

Das man mittels einfacher Verwendung von PHP5 (mit dem neuen Client) anstelle von PHP4 (mit dem alten Client) das Problem ohne Neukompilation vom Tisch bekommt bei 1&1-Accounts, war die für den OP wesentliche Aussage. Manuel wird kaum Zugriff auf die Konfiguration der PHP-Version bei 1&1 haben.

Richtig, aber er hat Zugriff auf seine Datenbank. Dort kann man (vgl. die verlinkte Seite) dem Useraccount auch ein altes Passwort geben, welches dann mit dem alten Client auch funktioniert.

Selbstverständlich kann man auch bei PHP4 den Client für MySQL austauschen. Das erfordert aber einigen Aufwand und außerdem geeigneten Zugriff auf den Server.

Das war ja auch nicht meine Aussage. Meine Aussage war: Es ist das Client-Problem, und für dessen Behebung gibt es viele Ansatzpunkte - siehe Doku.

Du könntest die notwendigen Schritte allerdings gerne mal hier darlegen.
Dafür wäre ich Dir dankbar. Der Thread würde dann bestimmt oft gelesen werden.

Ich habe die Manual-Page zu MySQL verlinkt - da steht alles drin, was man wissen muß.

Allerdings entgeht mir momentan der Grund dafür, warum man dann nicht gleich von PHP 4.x auf PHP 5.1 ff updaten sollte. Gibt es noch eine Distribution von PHP 5.1 ff, die den alten MySQL-Client verwendet?

PHP und MySQL sind nicht fest miteinander gekoppelt. Die Versionsnummern "4" und "5" sind nur zufällig identisch.

Wenn man sich PHP kompiliert, dann wird zu diesem Zeitpunkt die aktuell vorhandene MySQL-Client-Bibliothek eingebunden. Wenn man sich also PHP 5 kompiliert, aber aus irgendeinem Grund noch MySQL 3.23 installiert hat, dann kriegt man mit Sicherheit nur den alten Client eingebunden. Ein späteres Update auf MySQL 4.1 oder 5 würde daran erstmal nichts ändern, sondern führt zu dem aufgetretenen Fehler - allerdings nur bei Accounts, die unter der neuen Datenbankumgebung neu angelegt wurden. Die alten Accounts, die einfach in die neue Version migriert wurden, behalten dabei natürlich ihren alten Passwort-Hash und werden dadurch nicht inkompatibel. Allerdings gilt das nur bis zum nächsten Ändern des Passwortes dieser Accounts.

Dieses Szenario gilt auch für alle sonstigen, vorgefertigten PHP-Pakete, die eine feste Kombination aus PHP und MySQL-Client mitbringen. Wenn man sich beispielsweise XAMPP installiert, aber auf eine anderswo untergebrachte MySQL-Datenbank zugreifen will, dann können Client- und Serverversion ebenfalls unpassend sein.

- Sven Rautenberg

[Tom]

Hello,

Richtig, aber er hat Zugriff auf seine Datenbank. Dort kann man (vgl. die verlinkte Seite) dem Useraccount auch ein altes Passwort geben, welches dann mit dem alten Client auch funktioniert.

Das würde ich aber nicht empfehlen, gerade dann, wenn die DB übers Internet (ohne VPN) connectiert wird.

Allerdings entgeht mir momentan der Grund dafür, warum man dann nicht gleich von PHP 4.x auf PHP 5.1 ff updaten sollte. Gibt es noch eine Distribution von PHP 5.1 ff, die den alten MySQL-Client verwendet?

PHP und MySQL sind nicht fest miteinander gekoppelt. Die Versionsnummern "4" und "5" sind nur zufällig identisch.

Das sollte jedem klar sein. Denn sonst würden sicher alle Programme den Beinamen "Vista" tragen oder eben 'was vergleichbares ;-)

Wenn man sich PHP kompiliert, dann wird zu diesem Zeitpunkt die aktuell vorhandene MySQL-Client-Bibliothek eingebunden. Wenn man sich also PHP 5 kompiliert, aber aus irgendeinem Grund noch MySQL 3.23 installiert hat, dann kriegt man mit Sicherheit nur den alten Client eingebunden. Ein späteres Update auf MySQL 4.1 oder 5 würde daran erstmal nichts ändern, sondern führt zu dem aufgetretenen Fehler - allerdings nur bei Accounts, die unter der neuen Datenbankumgebung neu angelegt wurden. Die alten Accounts, die einfach in die neue Version migriert wurden, behalten dabei natürlich ihren alten Passwort-Hash und werden dadurch nicht inkompatibel. Allerdings gilt das nur bis zum nächsten Ändern des Passwortes dieser Accounts.

Darüber hatte ich eben allerdings nicht nachgedacht und somit war es schon wieder wert, an diesem Sonntag aufzustehen und ins Forum zu schauen. Latent im Hinterkopf war mir zwar bekannt, dass beim Kompilieren selbstverständlich nur vorhandene Elemente eingebunden werden können, aber es ist mir eben erst wieder richtig bewusst geworden, was man beim Update eines Programmteiles ggf. noch an Kettenreaktion vor sich hat.

Danke für die wertvollen Hinweise und einen wunderschönen Sonntag noch

BTW:
Bei uns ist es heute richtig warm und ich werde gleich zur Matthias-Baude aufsteigen, um meinem Zeitungshelfer Lukas, der dort heute Konfirmation feiert, ein kleines Dankeschön für die zuverlässige Mitarbeit zu bringen. Man muss zu Fuß gehen (oder mit dem Sesselligt fahren). Auto ist verboten... Ist wirkklich urig da drüben.
Wird sicher gut gegen meinen Bauch sein :-)

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Richtig, aber er hat Zugriff auf seine Datenbank. Dort kann man (vgl. die verlinkte Seite) dem Useraccount auch ein altes Passwort geben, welches dann mit dem alten Client auch funktioniert.

Das würde ich aber nicht empfehlen, gerade dann, wenn die DB übers Internet (ohne VPN) connectiert wird.

Sorry, aber unverschlüsselte Datenübertragung mit der Datenbank ist sowieso nicht zu empfehlen - egal welche Clientversion genutzt wird.

Ich schätze nur, dass auch keiner deiner Business-Kunden bei 1&1 VPN installieren kann, um damit "nach Hause" zur Datenbank zu connecten. SSL hingegen gibts, VPN wäre mir zu übertrieben.

- Sven Rautenberg

[Tom]

Hello,

Ich schätze nur, dass auch keiner deiner Business-Kunden bei 1&1 VPN installieren kann, um damit "nach Hause" zur Datenbank zu connecten. SSL hingegen gibts, VPN wäre mir zu übertrieben.

Im Zeitalter von Schäuble und Co ist nichts mehr übertrieben!

Dass Datentransfer-Logging sowieso schon seit Jahren betrieben wird won Odd und der Welt, dass ist wohl kein Gerücht, oder würdest Du das meinen?

Dass die Ausnutzung der Erkenntnisse aus diesen Methoden demnächst auch erlaubt sein soll, ist meiner Meinung nach ein impliziter Aufruf zur Revolution.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Vinzenz Mai]

Hallo Tom,

Richtig, aber er hat Zugriff auf seine Datenbank. Dort kann man (vgl. die verlinkte Seite) dem Useraccount auch ein altes Passwort geben, welches dann mit dem alten Client auch funktioniert.

Das würde ich aber nicht empfehlen, gerade dann, wenn die DB übers Internet (ohne VPN) connectiert wird.

welchen Unterschied macht es denn, ob ich einen Hashwert, der aus dem altem
Algorithmus resultiert oder einen Hashwert, der mit dem neuem Verfahren
erstellt wurde, abfange und missbrauche?

Sicherheit bietet hier nur eine verschlüsselte Übertragung, siehe
https://forum.selfhtml.org/?t=152075&m=989117f. Ich wüsste nicht,
dass MySQL das von Daniel szizzierte Verfahren anwendet.

Freundliche Grüße

Vinzenz

[Manuel Strunck]

Moin!

Wenn ich dich richtig verstehe, hätte folgendes vorgehen also auch Erfolg gehabt:
Ich Erstelle ein Passwort, dass den älteren, kürzeren Hashwert hat. Ich nutze also die "alte" PASSWORD()-Funktion von MySql. Das sollte ja machbar sein.
In der neueren MySql-5er Version erstelle ich dann einen Benutzer, am besten mit Zugriffsrechten nur vom 1und1-Webspace. In der Usertable von Mysql trage ich dann den Hashwert, welchen ich mit der PASSWORD()-Funktion generiert habe, ein.

So long
Manuel

[Manuel Strunck]

Moin!

Ein wechsel auf PHP5 hat tatsächlich geholfen. (Ganz nebenbei ist hat sich damit auch ein Problem mit der Zeichensatz kodierung erledigt, UTF-8 wollte einfach nicht, nun gehts plötzlich.)

Wenn ich Sven Rautenberg richtig verstanden habe, müsste die von 1und1 verwendete 5.2.1er PHP-Servion einen neuen Client und damit einen kompatiblen eingebunden haben.

Zum 1und1 support, als ich dort vorhin anrief habe ich mich ganz klar ausgedrück: Ich möchte von meinem 1und1-Webspace aus zu einer Datenbank konnektieren die nicht zu 1und1 gehört. Antwort: Nein, das geht nicht weils durch die FW geblockt wird.
Offenbar höhren die überhaupt nicht hin und dachten ich möchte mich von  außen (nicht 1und1 Account) zur 1und1 Datenbank verbinden.

So long und schönen Sonntag noch...

[Sven Rautenberg]

Moin!

Zum 1und1 support, als ich dort vorhin anrief habe ich mich ganz klar ausgedrück: Ich möchte von meinem 1und1-Webspace aus zu einer Datenbank konnektieren die nicht zu 1und1 gehört. Antwort: Nein, das geht nicht weils durch die FW geblockt wird.
Offenbar höhren die überhaupt nicht hin und dachten ich möchte mich von  außen (nicht 1und1 Account) zur 1und1 Datenbank verbinden.

Nein, 1&1 setzt schon Firewalls ein, die den Kontakt auch vom Server nach außen ins Internet begrenzen.

Nur offenbar weiß der Support nicht, welche Verbindungen das im einzelnen sind. Ich habe beispielsweise feststellen müssen, dass SMTP nach außen nicht funktioniert (fsockopen scheitert), sondern der Mailversand per mail() realisiert werden muß. Zumindest bei den einfacheren Accounts.

Es gibt also genügend Grund zu der Annahme, dass auch Verbindungen zu externen Datenbanken geblockt werden könnten.

- Sven Rautenberg

[Tom]

Hello,

Es gibt also genügend Grund zu der Annahme, dass auch Verbindungen zu externen Datenbanken geblockt werden könnten.

Dann wollen wir nur hoffen, dass wir sie nicht auf eine neue Idee gebracht haben.
Aber andereseits würde das garantiert eine Menge von Stornierungen bei Business-Accounts geben.
Ich habe jedenfalls keinen Kunden, der seine DB nicht im eigenen Hause (notfalls über DynDNS) hostet.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Dann wollen wir nur hoffen, dass wir sie nicht auf eine neue Idee gebracht haben.
Aber andereseits würde das garantiert eine Menge von Stornierungen bei Business-Accounts geben.
Ich habe jedenfalls keinen Kunden, der seine DB nicht im eigenen Hause (notfalls über DynDNS) hostet.

Die Datenbank möglichst weit weg vom Webserver zu platzieren zeugt ja auch nicht gerade von Professionalität. Insofern wäre eine Kündigung von Business-Accounts sicher folgerichtig.

Die Anbindung mit DynDNS ist noch grausamer.

- Sven Rautenberg

[Manuel B.]

Ich grüsse den Cosmos,

Warning: mysql_connect() [function.mysql-connect]: Client does not support authentication protocol requested by server; consider upgrading MySQL client in...

Das sagt nicht aus, das die PHP-Version nicht stimmt, sondern das die MySQL-Client-Libs nicht übereinstimmen.
Solche Fehlermeldungen entstehen z.B. wenn man mit den Mysql4-Libs auf Mysql5 zugreifen will, da Mysql5 mit verschlüsselungen arbeitet, die Mysql4 noch nicht kennt.

Möge das "Self" mit euch sein

[MudGuard]

Hi,

Warning: mysql_connect() [function.mysql-connect]: Client does not support authentication protocol requested by server; consider upgrading MySQL client in...

IIRC kommt diese Fehlermeldung dann, wenn

1. der Client ziemlich alt ist (IIRC < MySQL 4.1)
2. der MySQL-Server mind. (IIRC) 4.1
3. in der user-Tabelle des MySQL-Servers die Paßwörter mit der password()-Methode verschlüsselt wurden statt mit old_password()

Lösungsmöglichkeiten:

• Upgrade des Clients
• Verwendung von old_password() für die Paßwörter

cu,
Andreas