it-swarm.com.de

MYSQL ERROR 2049 (HY000): Verbindung unter Verwendung der alten (vor 4.1.1) Authentifizierungsprotokollreferenz verwendet (Client-Option 'Secure_auth' aktiviert)

als ich versuchte, den gesamten Datenbankspeicherauszug in Version 5.0 auf Version 5.6 wiederherzustellen, wurde er wiederhergestellt. Wenn ich danach versuchte, die Verbindung wiederherzustellen, wird der folgende Fehler angezeigt

ERROR 2049 (HY000): Connection using old (pre-4.1.1) authentication protocol ref used (client option 'secure_auth' enabled)..

Ich habe versucht, die folgenden Zeilen in My.ini hinzuzufügen und den Dienst neu zu starten, aber das Problem besteht bis.

skip-Grant-Tabellen Der folgende Link besagt, dass es sich um einen Fehler in MYSQL handelt.

https://github.com/santisaez/powerstack/blob/master/packages/mysql/mysql-powerstack-secure_auth.patch

Hat jemand irgendwelche Korrekturen für diese Lösung?

9

Dies ist kein Fehler, wenn Sie Benutzerkonten mit Kennwörtern haben, die den alten Hashing-Algorithmus verwendet haben. Wenn Sie den Fehlerbericht lesen, der in dem von Ihnen geposteten Link erwähnt ist:

http://bugs.mysql.com/bug.php?id=69027

[1. Mai 15:24] Todd Farmer

Die Problemumgehung (eigentlich "Lösung") besteht darin, das Kennwort für den betroffenen Benutzer in einen Post-4.1-Hash zu ändern. Dies ist eine empfohlene bewährte Methode, unabhängig davon - der Kennwort-Hashing- und Autorisierungsprozess vor 4.1 weist erhebliche Sicherheitsbeschränkungen auf (siehe Dokumentation unter http://dev.mysql.com/doc/refman/5.0/en/password) -hashing.html ).

Das Wiederherstellen einer 5.0-Version des Schemas mysql auf einem 5.6-Server ist auf jeden Fall eine schlechte Idee, da 5.6 in einigen Tabellen zusätzliche Spalten und einige völlig neue Tabellen enthält, die je nach Bedarf möglicherweise fehlen oder nicht wie Sie mysqldump konfiguriert haben, als Sie die Dump-Datei erstellt haben. Möglicherweise haben Sie andere Probleme verursacht, die Sie möglicherweise nicht sofort sehen.

Außerdem wurde skip-grant-tables Im Artikel nicht erwähnt ... Wenn Sie diese Option jedoch korrekt auf den Server anwenden, wird die gesamte Authentifizierung umgangen und Sie sollten sich anmelden und Kennwörter zurücksetzen können.

6

Verwenden Sie in der Befehlszeile Folgendes, wenn Sie keine andere Wahl haben ...

mysql -uTheUseerNAme -pThePassword DbName -h HostName --skip-secure-auth

Hoffe das hilft jemandem, da dies mein Problem war, eine Verbindung von einem Linux herzustellen

8
ShaunOReilly

Wenn Sie MySQL Workbench verwenden, müssen Sie diese Option aktivieren:

enter image description here

6

Dies ist eigentlich als Kommentar zur vorherigen Antwort gedacht, aber zu groß, um in einen StackExchange-Kommentar zu passen.

Auch ich litt unter diesem Problem. Also habe ich einen neuen Benutzer mit einem neuen Hash erstellt und verwende diesen neuen Benutzer jetzt ohne Probleme. Folgendes habe ich getan:

    [172.16.2.222:mysql Thu Nov  7 16:16:25 2013]> use mysql;
    Database changed
    [172.16.2.222:mysql Thu Nov  7 16:22:23 2013]> describe user;
    describe user;
    +-----------------------+-----------------------------------+------+-----+---------+-------+
    | Field                 | Type                              | Null | Key | Default | Extra |
    +-----------------------+-----------------------------------+------+-----+---------+-------+
    | Host                  | char(60)                          | NO   | PRI |         |       |
    | User                  | char(16)                          | NO   | PRI |         |       |
    | Password              | char(41)                          | NO   |     |         |       |

Ich war froh zu sehen, dass unsere Passwortspalte bereits breit genug war, um Hashes neuen Stils aufzunehmen. (Wäre es weniger als 41 Zeichen breit gewesen, hätte ich vielleicht nicht den Mut gehabt, es zu erweitern :-)

    [172.16.2.222:mysql Thu Nov  7 16:13:10 2013]> show variables like '%pass%';
    +-----------------+-------+
    | Variable_name   | Value |
    +-----------------+-------+
    | old_passwords   | ON    |
    | report_password |       |
    +-----------------+-------+
    2 rows in set (0.06 sec)

old_passwords Sein ON ist eindeutig das Problem, deshalb habe ich es vorübergehend geändert:

    [172.16.2.222:mysql Thu Nov  7 16:13:59 2013]> set session old_passwords = 'OFF';
    Query OK, 0 rows affected (0.05 sec)

    [172.16.2.222:mysql Thu Nov  7 16:14:12 2013]> show variables like '%pass%';
    show variables like '%pass%';
    +-----------------+-------+
    | Variable_name   | Value |
    +-----------------+-------+
    | old_passwords   | OFF   |
    | report_password |       |
    +-----------------+-------+
    2 rows in set (0.06 sec)

Dann habe ich einen neuen Benutzer erstellt:

    [172.16.2.222:mysql Thu Nov  7 16:14:16 2013]> create user 'erich' IDENTIFIED BY 'SEKRIT PASSWORD';

... und warf einen Blick auf den neuen Hash:

    [172.16.2.222:mysql Thu Nov  7 16:14:26 2013]> select * from user order by User;
    +-----------+--------------+-------------------------------------------+--------
    | Host      | User         | Password                                  | Select_
    +-----------+--------------+-------------------------------------------+--------
    | localhost | someguy      | 3d9505dd323e53f1                          | Y      
    | %         | someotherguy | 79b3df3b004bb855                          | Y      
    | %         | erich        | *D2589EF6B59146801234567897BB190123456789 | N      
    | %         | anotheroldguy| 60577e0d77b9212b                          | Y      

Beachten Sie, wie mein Hash größer ist als die anderen!

Um ordentlich zu sein, setze ich old_passwords zurück zu OFF. Dies war wahrscheinlich sinnlos, da ich mir nicht vorstellen kann, warum jemand neue Benutzer mit alten Passwörtern erstellen möchte, aber wer weiß.

Wie auch immer: das hat es für mich gelöst.

1
offby1