ERREUR MYSQL 2049 (HY000): Connexion utilisant l'ancienne référence de protocole d'authentification (antérieure à 4.1.1) utilisée (option client 'secure_auth' activée)

quand j'ai essayé de restaurer tout le vidage de la base de données qui est dans la version 5.0 vers la version 5.6, il a été restauré et après cela, lorsque j'ai essayé de me reconnecter, j'obtiens l'erreur suivante

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

J'ai essayé d'ajouter les lignes suivantes dans My.ini et redémarré le service, mais le problème persiste jusqu'à.

skip-grant-tables Le lien suivant indique qu'il s'agit d'un bogue dans MYSQL.

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

Quelqu'un at-il des correctifs pour cette solution?

Ce n'est pas un bogue si vous avez des comptes d'utilisateurs avec des mots de passe qui utilisaient l'ancien ancien algorithme de hachage. Si vous lisez le rapport de bogue mentionné dans le lien que vous avez publié:

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

[1 mai 15:24] Todd Farmer

La solution de contournement ("solution", en fait) consiste à remplacer le mot de passe de l'utilisateur concerné par un hachage post-4.1. C'est vraiment une meilleure pratique recommandée, indépendamment - le hachage de mot de passe et le processus d'autorisation avant 4.1 ont des limitations de sécurité notables (discutées dans la documentation à http://dev.mysql.com/doc/refman/5.0/en/password-hashing.html ).

Restaurer une version 5.0 du mysqlschéma sur un serveur 5.6 est en tout cas une mauvaise idée, car 5.6 a des colonnes supplémentaires dans certaines tables et des tables complètement nouvelles, qui peuvent ou non manquer maintenant selon la façon dont vous avez configuré mysqldump lorsque vous créé le fichier de vidage. Vous avez peut-être causé d'autres problèmes que vous ne voyez peut-être pas immédiatement.

De plus, je n'ai pas vu skip-grant-tablesmentionné dans l'article ... mais si vous appliquez correctement cette option au serveur, toute l'authentification est contournée et vous devriez pouvoir vous connecter et réinitialiser les mots de passe.

Sur la ligne de commande, utilisez quelque chose comme ce qui suit, si vous n'avez pas le choix ...

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

J'espère que cela aide quelqu'un, car c'était mon problème de connexion à partir d'un Linux

Si vous utilisez MySQL Workbench, vous devez cocher cette option:

Il s'agit en fait d'un commentaire sur la réponse précédente, mais il est trop volumineux pour tenir dans un commentaire StackExchange.

Moi aussi, je souffrais de ce problème. J'ai donc créé un nouvel utilisateur avec un hachage de nouveau style, et j'utilise maintenant ce nouvel utilisateur sans problème. Voici ce que j'ai fait:

    [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   |     |         |       |

J'étais heureux de voir que notre colonne Mot de passe était déjà suffisamment large pour contenir des hachages de nouveau style. (S'il avait moins de 41 caractères de large, je n'aurais peut-être pas eu le courage de l'élargir :-)

    [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_passwordsl'être ONest clairement le problème, donc je l'ai changé temporairement:

    [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)

J'ai ensuite créé un nouvel utilisateur:

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

... et jette un œil au nouveau hachage:

    [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      

Notez à quel point mon hachage est plus gros que les autres!

Juste pour être bien rangé, je suis old_passwordsretourné àOFF . C'était probablement inutile, car je ne vois pas pourquoi quelqu'un voudrait créer de nouveaux utilisateurs en utilisant d'anciens mots de passe, mais qui sait.

Quoi qu'il en soit: cela l'a résolu pour moi.