MYSQL错误2049(HY000):使用旧的(4.1.1之前版本)身份验证协议ref的连接(启用了客户端选项“ secure_auth”)


9

当我尝试将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-tables以下链接说它是MYSQL中的错误。

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

有人对此解决方案有任何修补程序吗?

Answers:


6

如果您的用户帐户使用的密码使用的是古老的旧哈希算法,则这不是错误。如果您阅读发布的链接中提到的错误报告,则:

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

[5月1日15:24] Todd Farmer

解决方法(实际上是“解决方案”)是将受影响用户的密码更改为4.1后的哈希值。无论如何,这实际上都是建议的最佳做法-4.1之前的密码哈希和授权过程具有显着的安全限制(在http://dev.mysql.com/doc/refman/5.0/en/password-hashing.html的文档中讨论了))。

mysql无论如何,将5.0版本的模式恢复到5.6服务器上都是一个坏主意,因为5.6在某些表和一些全新的表中具有其他列,根据您配置mysqldump的方式,现在这些表可能会或可能不会丢失创建了转储文件。您可能造成了其他问题,而您可能不会立即看到。

另外,我没有看到skip-grant-tables文章中提到的内容……但是,如果您将该选项正确地应用于服务器,则会绕过所有身份验证,您应该能够登录并重置密码。


8

如果您别无选择,请在命令行上使用如下所示的内容...

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

希望这对某人有帮助,因为这是我从Linux连接时遇到的问题


这对我不起作用。我仍然收到错误消息。
fanchyna

6

如果使用MySQL Workbench,则需要检查以下选项:

在此处输入图片说明


虽然这适用于连接到数据库,但无法导入/导出的问题将继续存在。我已经测试并确认了这一点,因为我目前正在寻找一种允许使用旧的auth协议导入/导出数据的方法。
rkeet 2014年

谢谢!当我尝试使用Workbench连接时,它对我有用。
Huynh Vinh Phat 2015年

我发现此选项在工作台版本6.0.7中,但不在最新版本中。
Mian Asbat Ahmad

1

这实际上是对先前答案的注释,但是太大而无法放入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。这可能毫无意义,因为我不知道为什么有人会使用旧密码创建新用户,但谁知道。

无论如何:这为我解决了。


这是否可以解决OP的问题?如果没有,也许应该是它自己的问题和答案。
Max Vernon

@MaxVernon我认为这取决于OP来决定是否解决。它为我工作。
2013年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.