web-dev-qa-db-fra.com

Connexion utilisant l'ancien protocole d'authentification (antérieur à 4.1.1) refusée (option client 'secure_auth' activée)

J'ai un problème lors de la tentative de connexion à la base de données MySQL à l'aide du pilote OBDC Windows. Il y a beaucoup de résultats de recherche concernant l'évidence ... les gens utilisent d'anciennes versions, mais je ne le suis pas.

mysqld est sur CentOS 6.4 32 bits

./usr/libexec/mysqld  Ver 5.1.69 for redhat-linux-gnu on i386 (Source distribution)

enter image description here

Je ne sais donc pas d'où vient tout protocole pré 4.1.1. Des idées?

odbcmysql-error-1064
14
tlum

Je suppose que si vous posez la bonne question, il est plus facile de trouver la réponse.

Dans ce cas, "mon" problème concerne la façon dont les mots de passe sont hachés et stockés dans la base de données. Les mots de passe hérités ont été stockés avec un hachage plus court qui est désormais obsolète.

Quelques points importants:

mysql_upgrade ne peut pas et ne met pas à niveau les mots de passe, ni ne l'avertit dans certaines versions, voir: http://bugs.mysql.com/bug.php?id=65461 .

Même si vous avez principalement le dernier serveur et les derniers clients, il suffit d'un client hérité quelque part pour créer un mot de passe hérité et vous aurez alors des problèmes avec ce compte, quel que soit le client qui essaie de l'utiliser.

Différentes versions ont traité la situation différemment, vous pouvez donc vous asseoir sur certains mots de passe hérités dans votre base de données, puis tout à coup, sans raison apparente, certains comptes cessent de fonctionner ... c'est à cause de la façon dont les différentes versions ont choisi de gérer la situation.

Vous ne pouvez pas mettre à niveau les mots de passe. Vous devez savoir ce qu'ils sont et vous devez les changer.

EDIT: pour être plus clair, vous devez changer le mot de passe qui est stocké avec le hachage plus court en utilisant un nouveau client qui utilise des hachages plus longs. Ce faisant, vous écrirez le mot de passe du compte avec le hachage le plus long, auquel cas rien ne devrait plus signaler les tentatives d'accès au compte. Si le problème est récurrent, vous devriez rechercher les anciens clients de votre site qui écrivent toujours des mots de passe avec la longueur de hachage obsolète.

10
tlum

MySQL Workbench 6.08 dans l'onglet Gérer les connexions au serveur, onglet Connexion, sous-onglet Avancé, vous devez cocher la case 'tiliser l'ancien protocole d'authentification.'

9
Md Azaharuddin Ali

J'ai rencontré cela en utilisant le connecteur ODBC pour Windows pour se connecter à un serveur Percona 5.5. Qui a secure_auth Désactivé.

D'après ce que j'ai trouvé, le connecteur ODBC, contrairement à MySql Workbench, ne prend pas en charge une option pour authentifier les connexions qui utilisent les anciens mots de passe hachés de 16 octets. Il y a un rapport de bogue à ce sujet, mais il apparaît le cessionnaire est/était confus au sujet de la demande de fonctionnalité (Voir bug # 71234 ).

J'ai pu mettre à jour la connexion mysql pour utiliser le nouveau hachage de 41 octets en utilisant ces commandes:

 set old_passwords=0;
 set password=password('yourpasswordhere');

Comme je l'ai mentionné, notre serveur a désactivé secure_auth, Ce qui semble entraîner password() à renvoyer old_password() résultats. L'exécution de set old_passwords=0; Permettra à la méthode password() de générer les nouveaux hachages de 41 octets (pour la durée de votre session).

3
STW

Essayez d'installer l'ancienne version du pilote 3.51.30: http://dev.mysql.com/downloads/connector/odbc/5.1.html#downloads Cela fonctionne sur ma communauté Mysql Ver 5.0.24a

3
Sergey Bogdanov

J'ai eu un message d'erreur similaire lorsque j'essayais d'accéder à distance à ma base de données MySQL. En utilisant Directadmin, j'ai facilement changé le mot de passe de la base de données MySql comme suggéré ci-dessus. Cela a généré automatiquement le mot de passe à l'aide de la nouvelle méthode de hachage. Cela a résolu le problème de connexion à distance instantanément.

1
Shotputty

J'ai trouvé une autre solution au cas où quelqu'un toucherait ça - très bizarre -

  1. Installez le pilote 5.1 64 bits ODBC - vérifiez qu'une connexion ODBC en elle-même fonctionne, si vous pouvez vous connecter, vous devriez pouvoir après avoir fait # 2
  2. Cliquez sur Serveurs liés - Fournisseurs - faites un clic droit sur MSDASQL, cliquez sur Propriétés
    • décochez "Autoriser inprocess" - ce qui est une bonne chose à faire, sauf si vous devez insérer des champs TEXT et NTEXT.
  3. Créez votre connexion au serveur lié ou testez celle avec laquelle vous vous êtes battu - lol

Quand j'avais "Autoriser inprocess" coché, j'ai quand même eu l'erreur même si le DSN système ODBC fonctionnait bien. Je suppose que j'avais un mélange de 5.2 (avec des serveurs qui fonctionnaient bien) et 5.1 pour les serveurs qui ne l'ont pas fait, SQL partageait les processus car le pilote 5.1 ne donne pas cette erreur.

0
Mike

Si vous ne pouvez pas changer votre serveur, vous pouvez peut-être changer votre client: http://bugs.mysql.com/bug.php?id=75425

0
niczero