MYSQL ERROR 2049 (HY000): Użyto połączenia przy użyciu starego protokołu uwierzytelniania (wcześniejszego niż 4.1.1) (włączona opcja klienta „secure_auth”)

kiedy próbowałem przywrócić cały zrzut bazy danych, który jest w wersji 5.0 do wersji 5.6, został przywrócony, a następnie, gdy próbowałem ponownie połączyć, pojawia się następujący błąd

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

Próbowałem dodać następujące wiersze w My.ini i ponownie uruchomiłem usługę, ale problem nadal występuje do.

Skip-Grant-Table Poniższy link mówi, że jest to błąd w MYSQL.

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

Czy ktoś ma jakieś poprawki do tego rozwiązania?

To nie jest błąd, jeśli masz konta użytkowników z hasłami, które korzystały ze starożytnego algorytmu haszującego. Jeśli przeczytasz raport o błędzie wymieniony w opublikowanym linku:

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

[1 maja 15:24] Todd Farmer

Obejściem („rozwiązaniem” tego problemu) jest zmiana hasła dla użytkownika, którego dotyczy problem, na hash po 4.1. Jest to naprawdę zalecana najlepsza praktyka, niezależnie od tego - proces mieszania hasła i proces autoryzacji przed wersją 4.1 ma znaczące ograniczenia bezpieczeństwa (omówione w dokumentacji na stronie http://dev.mysql.com/doc/refman/5.0/en/password-hashing.html ).

Przywrócenie wersji 5.0 mysqlschematu na serwerze 5.6 jest w każdym razie złym pomysłem, ponieważ 5.6 ma dodatkowe kolumny w niektórych tabelach i niektóre zupełnie nowe tabele, których może teraz brakować, w zależności od tego, jak skonfigurowałeś mysqldump podczas utworzył plik zrzutu. Możliwe, że spowodowałeś inne problemy, których możesz od razu nie zobaczyć.

Ponadto nie widziałem skip-grant-tableswspomnianego w artykule ... ale jeśli poprawnie zastosujesz tę opcję do serwera, całe uwierzytelnianie zostanie pominięte i powinieneś być w stanie zalogować się i zresetować hasła.

W wierszu polecenia użyj czegoś takiego jak poniżej, jeśli nie masz wyboru ...

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

Mam nadzieję, że to komuś pomoże, ponieważ był to mój problem z połączeniem z Linuksem

Jeśli korzystasz z MySQL Workbench, musisz zaznaczyć tę opcję:

To naprawdę jest komentarzem do poprzedniej odpowiedzi, ale jest zbyt duży, aby zmieścił się w komentarzu StackExchange.

Ja też cierpiałem na ten problem. Więc stworzyłem nowego użytkownika z hashem w nowym stylu i teraz używam tego nowego użytkownika bez żadnych problemów. Oto co zrobiłem:

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

Cieszyłem się, że nasza kolumna z hasłem była już wystarczająco szeroka, aby pomieścić skróty w nowym stylu. (Gdyby miał mniej niż 41 znaków, nie miałbym odwagi go poszerzyć :-)

    [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_passwordsbycie ONjest oczywiście problemem, więc tymczasowo to zmieniłem:

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

Następnie utworzyłem nowego użytkownika:

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

... i spojrzał na nowy skrót:

    [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      

Zauważ, że mój skrót jest większy od innych!

Żeby być czystym, old_passwordswróciłem do OFF. Prawdopodobnie było to bezcelowe, ponieważ nie wiem, dlaczego ktoś chciałby tworzyć nowych użytkowników przy użyciu starych haseł, ale kto wie.

W każdym razie: to dla mnie rozwiązało.