web-dev-qa-db-fra.com

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, quand 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 a-t-il des correctifs pour cette solution?

mysqlauthentication
9
Praveen Prasannan

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, peu importe - le processus de hachage et d'autorisation des mots de passe avant 4.1 a 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 schéma mysql 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 comment vous avez configuré mysqldump lorsque vous avez 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-tables mentionné 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.

6
Michael - sqlbot

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

8
ShaunOReilly

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

enter image description here

6
Franck Dernoncourt

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_passwords étant ON est 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 mets old_passwords retour à 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.

1
offby1