MYSQL ERROR 2049 (HY000): підключення за допомогою старого (до 4.1.1) протоколу автентифікації, який використовується, (опція клієнта 'secure_auth' включена)

коли я спробував відновити весь дамп бази даних, який знаходиться у версії 5.0 до версії 5.6, він відновився, і після цього, коли я намагався знову підключитися, отримую наступну помилку

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

Я спробував додати наступні рядки в My.ini та перезапустив службу, але проблема зберігається до цього часу.

skip-grant-table Наступне посилання говорить про помилку в MYSQL.

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

Хтось має виправлення цього рішення?

Це не помилка, якщо у вас є облікові записи користувачів із паролями, які використовували старий старий алгоритм хешування. Якщо ви читаєте звіт про помилку, згаданий у посиланні, яке ви опублікували:

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

[1 травня 15:24] Тодд Фермер

Вирішення проблеми (дійсно) для цього - змінити пароль для постраждалого користувача на хеш після 4.1. Це дійсно рекомендована найкраща практика, незалежно від того, що хешування паролів та процес авторизації до 4.1 має помітні обмеження безпеки (обговорюється в документації за адресою http://dev.mysql.com/doc/refman/5.0/uk/password-hashing.html ).

Відновлення версії 5.0 на mysqlсхемі на сервері 5.6 - це погана ідея, тому що 5.6 має додаткові стовпці в деяких таблицях та деякі абсолютно нові таблиці, які можуть бути, а можуть і не бракувати зараз, залежно від способу налаштування mysqldump, коли ви створили дамп-файл. Можливо, ви спричинили інші проблеми, які ви можете побачити не відразу.

Крім того, я не бачив skip-grant-tablesзгадки в статті ... але якщо ви правильно застосуєте цю опцію до сервера, вся автентифікація обходить обхід, і ви повинні мати можливість увійти та скинути паролі.

У командному рядку використовуйте щось подібне, якщо у вас немає вибору ...

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

Сподіваюся, це допоможе комусь, оскільки це була моя проблема підключення до Linux

Якщо ви використовуєте MySQL Workbench, вам потрібно перевірити цей параметр:

Це справді мається на увазі як коментар до попередньої відповіді, але занадто велике, щоб вмістити коментар StackExchange.

Я теж страждав від цієї проблеми. Тому я створив нового користувача з хешем у новому стилі, і тепер користуйтеся цим новим користувачем без проблем. Ось що я зробив:

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

Я був радий побачити, що наш стовпець пароля вже досить широкий, щоб вмістити хеші нового стилю. (Якби його було менше 41 символу, я, можливо, не мав би сміливості розширити це :-)

    [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істота ONявно проблема, тому я тимчасово змінив його:

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

Потім я створив нового користувача:

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

... і подивився на новий хеш:

    [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      

Зауважте, наскільки мій хеш більший за інші!

Тільки щоб бути охайним, я old_passwordsповернувся до OFF. Це, мабуть, було безглуздо, оскільки я не можу подумати, чому хтось хотів би створити нових користувачів за допомогою старих паролів, але хто знає.

У всякому разі: це вирішило це для мене.