Mysql root не работает

Решение проблем с правами доступа в MySQL: вопросы и ответы

В феврале этого года Света Смирнова (ведущий инженер компании Percona) провела вебинар, посвященный решению проблем с правами доступа в MySQL. Запись и слайды с вебинара доступны здесь. Предлагаем вашему вниманию небольшой обзор самых популярных вопросов на эту тему.

Какие права нужно давать пользователю root@localhost: ALL или Super? Включают ли права All и Super права тоже?

У вас обязательно должен быть пользователь с полными правами. Лучше, если у этого пользователя будет доступ только из localhost. Права ALL включают права SUPER.

У нас есть пользователи, подключающиеся с ноутбуков, которые получают динамические IP-адреса, так что предоставление доступа через имя сервера — наиболее простой способ управления этими пользователями. Можно ли предоставить доступ к базе данных MySQL с помощью имени хоста, а не IP-адреса? Например, myname@mymachine.mydomain.com вместо “myname@10.10.10.10”? Требуется ли для этого кэш хоста/performance_schema?

Да, можно. Но похоже, я недостаточно разъяснила, что такое кэш хоста. Это внутренняя структура, которая всегда доступна и содержит ответы от DNS-сервера. Вы не можете включить его или выключить. До версии 5.6 вы также не могли контролировать его. К примеру, если кэш оказался поврежден, единственное, что вы могли сделать — это перезапустить сервер. В версии 5.6 таблица HOST_CACHE была представлена в Performance Schema. С помощью этой таблицы вы можете проверить содержимое кэша хоста и, при необходимости, очистить его.

Если в таблице пользователей имеется несколько записей, которые соответствуют подключаемому пользователю (например, через шаблоны, имя хоста и IP), по каким правилам MySQL выбирает, какая из них будет использоваться для аутентификации? Будет ли он проверять каждую, пока не получит совпадение пароля?

Нет, mysqld не пытается взломать ваши пароли. Вместо этого он сортирует таблицу пользователей по имени и хосту в порядке убывания, как показано на слайде №37 (стр. 110). Затем он берет первую подходящую строку. То есть, если вы создали пользователей foo@somehost, foo@some% и foo@1.2.3.4, а подключаетесь как foo из somehost, mysqld сначала проверяет имя пользователя, а затем выбирает первую подходящую строку foo@somehost. Если вместо этого вы подключаетесь как foo от someotherhost, mysqld выбирает foo@some%. Хост на базе IP выбирается, либо если mysqld запущен с опцией skip-networking, либо если 1.2.3.4 указывает на хост, чье имя не начинается с «some».

Смешивание хостов на основе IP с хостами на основе имен опасно в ситуациях, когда один и тот же хост может быть принят и как somehost, и как 1.2.3.4. В этом случае, если что-то пойдет не так с кэшем хоста или DNS-сервером, может быть выбрана неправильная запись из таблицы пользователей. Допустим, первоначально у вас было три хоста: uniquehost (который преобразовывается как 1.2.3.4), somehost (который преобразовывается как 4.3.2.1) и someothershost (который преобразовывается как 4.3.2.2). Теперь вы решили переместить uniquehost на машину с IP 1.2.3.5 и использовать IP 1.2.3.4 для хоста с именем someyetanotherhost. В этом случае клиенты с машины с IP 1.2.3.4 будут рассматриваться как foo@some%, а это совсем не то, что вы хотели.

Чтобы продемонстрировать этот случай, я создала двух пользователей и выдала им два разных набора прав:

Затем я изменила файл /etc/hosts и указала адрес 192.168.0.4 для имени Thinkie:

Теперь если я подсоединюсь как sveta, и Thinkie, и 192.168.0.4 будут преобразованы в один и тот же хост:

После этого я изменила файл /etc/hosts и снова привязала Thinkie к 127.0.0.1 (localhost):

Но хост 192.168.0.4 по-прежнему преобразовывается в Thinkie:

Причиной этого является устаревший кеш хоста, что хорошо видно в Performance Schema:

После очистки таблицы host_cache числовой хост преобразовывается так, как я ожидаю:

Какие права требуются не root и не super пользователю, чтобы использовать mysqldump для сброса базы данных и последующего ее восстановления на другом сервере?

Как правило, вы должны иметь права SELECT для всех объектов, которые вы собираетесь сбросить. Если вы сбрасываете представления, у вас также должны быть права SHOW VIEW для запуска SHOW CREATE TABLE. Если вы хотите сбросить хранимые процедуры/события, вам также нужен доступ к ним. Если вы используете опцию —lock-tables или —lock-all-tables, у вас должны быть права LOCK.

Если в MySQL достигнуто значение max_connection, может ли залогиниться root@localhost с правами ALL или пользователь с правами Super?

ALL включает SUPER, так что пользователь с правами ALL сможет залогиниться. Но имейте в виду, что такое соединение может быть только одно, поэтому не выдавайте права SUPER или ALL пользователю приложения.

Можно ли удалить привилегию на более низком уровне? Другими словами, разрешить выбирать и удалять на уровне базы данных, но запретить удаление для конкретной таблицы? Или привилегии можно только добавлять?

Нет, MySQL отклонит такой запрос:

Каким образом можно организовать пользовательские роли… в виде группы грантов для конкретной роли?

У вас есть несколько вариантов:

1. Использовать MariaDB 10.0.5 или новее. Вы можете почитать о поддержке ролей в MariaDB здесь.
2. Использовать MySQL 8.0. Почитать о ролях в MySQL 8.0 можно здесь.
3. С помощью MySQL 5.7: имитировать роли так, как я показала на слайде 19 (стр. 53-60).
4. С помощью MySQL 5.5 и 5.6: использовать тот же метод, что на слайдах, но применить плагин кастомной аутентификации, поддерживающий прокси-пользователей.
5. Всегда: создать шаблон с правами, назначить права для каждого пользователя вручную.

Как бы вы мигрировали моделирование ролей с прокси-пользователями на фактические роли в MySQL 8.x?

Я бы удалила прокси-пользователя и создала роль с теми же правами, а затем назначила прокси-пользователю эту новую роль вместо PROXY.

Существует ли плагин для интеграции Active Directory и MySQL, чтобы использовать группы Active Directory?

Существует коммерческий плагин аутентификации Windows Authentication Plugin, доступный в версиях 5.5 и новее. Вы также можете использовать плагин аутентификации с открытым исходным кодом Percona PAM authentication plugin и подключить его к Active Directory так же, как это делается для LDAP. Есть статья, в которой описывается, как это сделать, но я сама никогда не использовала этот метод.

Можно ли использовать централизованную аутентификацию в MySQL?

Да, с помощью плагина PAM. Есть инструкции для LDAP и Active Directory. Вы можете использовать аналогичные методы для установки других видов аутентификации, таких как Kerberos.

Друзья, если работа с MySQL является для вас ежедневной задачей, обязательно приезжайте к нам на PG Day’17 Russia. Света Смирнова, Петр Зайцев и другие специалисты компании Percona готовят для вас увлекательные доклады и мастер-классы об устройстве и функционировании MySQL в рамках секции, посвященной базам данных с открытым исходным кодом.

Источник

MySQL Error:: ‘Доступ запрещен для пользователя’ root ‘@’ localhost ‘

$ ./mysqladmin -u root -p ‘ redacted ‘
Введите пароль:

mysqladmin: ошибка подключения к серверу при локальном хосте: ошибка:
«Отказано в доступе для пользователя root» @ «localhost» (с использованием пароля: ДА)

Как я могу это исправить?

1. Откройте и измените /etc/my.cnf или /etc/mysql/my.cnf , в зависимости от вашего дистрибутива.
2. Добавить skip-grant-tables под [mysqld]
3. Перезапустите Mysql
4. Вы должны иметь возможность войти в MySQL, используя команду ниже mysql -u root -p
5. Бегать mysql> flush privileges;
6. Установите новый пароль с помощью ALTER USER ‘root’@’localhost’ IDENTIFIED BY ‘NewPassword’;
7. Вернитесь в /etc/my.cnf и удалите / закомментируйте skip-grant-tables
8. Перезапустите Mysql
9. Теперь вы сможете войти с новым паролем mysql -u root -p

Все решения, которые я нашел, были намного сложнее, чем необходимо, и ни одно из них не помогло мне. Вот решение, которое решило мою проблему. Нет необходимости перезапускать mysqld или запускать его с особыми привилегиями.

С помощью одного запроса мы меняем auth_plugin на mysql_native_password и устанавливаем пароль root как root (смело меняйте его в запросе)

Теперь вы должны иметь возможность войти в систему с правами root. Более подробную информацию можно найти в документации MySQL

(выйдите из консоли mysql с помощью Ctrl + D или наберите exit )

Я попытался много шагов, чтобы исправить эту проблему. Существует так много источников возможных решений этой проблемы, что трудно отфильтровать смысл от бессмыслицы. Я наконец нашел хорошее решение здесь :

Шаг 1: Определите версию базы данных

Вы увидите некоторые результаты, как это с MySQL:

Или вывод, как это для MariaDB:

Запишите, какая база данных и какая у вас версия, так как вы будете использовать их позже. Затем вам нужно остановить базу данных, чтобы вы могли получить к ней доступ вручную.

Шаг 2. Остановка сервера базы данных

Чтобы сменить пароль пользователя root, вам необходимо заранее выключить сервер базы данных.

Вы можете сделать это для MySQL с:

И для MariaDB с:

Шаг 3. Перезапуск сервера базы данных без проверки разрешений.

Если вы запустите MySQL и MariaDB без загрузки информации о пользовательских привилегиях, это позволит вам получить доступ к командной строке базы данных с правами суперпользователя без предоставления пароля. Это позволит вам получить доступ к базе данных, не зная об этом.

Для этого вам нужно запретить базе данных загружать таблицы грантов, в которых хранится информация о привилегиях пользователя. Поскольку это немного угрожает безопасности, вам также следует пропустить сеть, чтобы предотвратить подключение других клиентов.

Запустите базу данных, не загружая таблицы грантов и не включая сеть:

Амперсанд в конце этой команды заставит этот процесс работать в фоновом режиме, чтобы вы могли продолжать использовать свой терминал.

Теперь вы можете подключиться к базе данных как пользователь root, который не должен запрашивать пароль.

Вместо этого вы сразу увидите приглашение оболочки базы данных.

MySQL Prompt

MariaDB Prompt

Теперь, когда у вас есть root-доступ, вы можете изменить пароль root.

Шаг 4: Изменение корневого пароля

Теперь мы можем изменить пароль root.

Для MySQL 5.7.6 и новее, а также MariaDB 10.1.20 и новее используйте следующую команду:

Для MySQL 5.7.5 и старше, а также MariaDB 10.1.20 и старше используйте:

Обязательно замените new_password ваш новый пароль на ваш выбор.

Примечание: если ALTER USER команда не работает, это обычно указывает на более серьезную проблему. Однако UPDATE . SET вместо этого вы можете попытаться сбросить пароль root.

[ВАЖНО] Это конкретная строка, которая исправила мою конкретную проблему:

Не забудьте перезагрузить таблицы грантов после этого.

В любом случае вы должны увидеть подтверждение того, что команда была успешно выполнена.

Пароль был изменен, поэтому теперь вы можете остановить ручной экземпляр сервера базы данных и перезапустить его, как это было раньше.

Шаг 5: Перезагрузите сервер базы данных в обычном режиме

Учебное пособие включает дальнейшие шаги для перезапуска базы данных, но единственная часть, которую я использовал, была следующей:

Для MySQL используйте: $ sudo systemctl start mysql

Для MariaDB используйте:

Теперь вы можете подтвердить, что новый пароль был введен правильно, запустив:

Теперь команда должна запросить вновь назначенный пароль. Введите его, и вы должны получить доступ к приглашению базы данных, как и ожидалось.

Вывод

Теперь у вас восстановлен административный доступ к серверу MySQL или MariaDB. Убедитесь, что выбранный вами новый пароль root является надежным и надежным, и храните его в надежном месте.

Источник

Ошибка MySQL:: «Доступ запрещен для пользователя «root» @ «localhost»

$ ./ mysqladmin-u root-p ‘удалено‘
Введите пароль:

mysqladmin: подключение к серверу в «localhost» ошибка:
‘Доступ запрещен для пользователя ‘root’ @ ‘ localhost ‘(используя пароль: да)’

Как я могу это исправить?

9 ответов

1. Открыть И Редактировать /etc/my.cnf
2. добавить skip-grant-tables под [mysqld]
3. Перезапустить Mysql
4. вы должны иметь возможность войти в mysql теперь, используя следующую команду mysql -u root -p
5. Run mysql> flush privileges;
6. установить новый пароль ALTER USER ‘root’@’localhost’ IDENTIFIED BY ‘NewPassword’;
7. вернитесь к /etc / my.cnf и удалить/комментарий пропустить-грант-столы
8. Перезапустить Mysql
9. теперь вы сможете войти в систему с новым паролем mysql -u root -p

все решения, которые я нашел, были намного сложнее, чем необходимо, и никто не работал для меня. Вот решение, которое решило мою проблему. Нет необходимости перезапускать mysqld или запускать его со специальными привилегиями.

С помощью одного запроса мы меняем auth_plugin to mysql_native_password и установка пароля root в root (не стесняйтесь изменять его в запросе)

теперь вы должны иметь возможность войти с корнем. Более подробную информацию можно найти в документация mysql

(выход из консоли mysql с Ctrl + D или путем ввода выход)

Я пробовал много шагов, чтобы исправить эту проблему. Существует так много источников для возможных решений этой проблемы, что трудно отфильтровать смысл от ерунды. Я наконец нашел хорошее решение здесь:

Шаг 1: Определите версию базы данных

вы увидите выход такой с MySQL:

или вывод, как это для MariaDB в:

обратите внимание, какую базу данных и какую версию вы используете, как вы будете использовать их позже. Затем вам нужно остановить базу данных, чтобы вы могли получить к ней доступ вручную.

Шаг 2: остановка сервера баз данных

чтобы изменить пароль root, необходимо предварительно выключить сервер баз данных.

вы можете сделать это для MySQL с помощью:

и MariaDB в с:

Шаг 3: перезапуск сервера баз данных без проверки разрешений

если вы запустите MySQL и MariaDB без загрузки информации о привилегиях пользователя, это позволит вам получить доступ к командной строке базы данных с правами root без предоставления пароля. Это позволит вам получить доступ к базе не зная ее.

для этого вам нужно остановить загрузку базы данных гранта таблицы, в которых хранятся сведения о привилегиях пользователя. Поскольку это немного опасно для безопасности, вы также должны пропустить сеть, чтобы предотвратить подключение других клиентов.

запустите базу данных без загрузки таблиц грантов или включения сети:

амперсанд в конце этой команды заставит этот процесс работать в фоновом режиме, чтобы вы могли продолжать использовать свой терминал.

теперь вы можете подключиться к базы данных как пользователь root, который не должен спрашивать пароль.

вместо этого вы сразу увидите приглашение оболочки базы данных.

MySQL Prompt

MariaDB В Строке

теперь, когда у вас есть доступ root, вы можете изменить пароль root.

Шаг 4: изменение пароля Root

теперь мы можем фактически изменить пароль root.

на MySQL 5.7.6 и новее а также MariaDB 10.1.20 и новее используйте следующую команду:

на в MySQL 5.7.5 и старше а также MariaDB 10.1.20 и старше использовать:

обязательно замените new_password с вашим новым паролем выбора.

Примечание: если ALTER USER команда не работает, это обычно указывает более серьезной проблемы. Тем не менее, вы можете попробовать UPDATE . SET для сброса пароля root вместо этого.

[важно] это конкретная строка, которая исправила мою конкретную проблему:

не забудьте перезагрузить таблицы после этого.

в любом случае, вы должны увидеть подтверждение, что команда выполнена успешно.

пароль был изменен, поэтому теперь вы можете остановить руководство экземпляр сервера базы данных и перезапустите его, как это было раньше.

Шаг 5: перезагрузите сервер базы данных обычно

учебник переходит к некоторым дальнейшим шагам по перезапуску базы данных, но единственная часть, которую я использовал, была такой:

для MySQL используйте: $ sudo systemctl запуск mysql

для MariaDB используйте:

вы можете подтвердить, что новый пароль правильно работает:

теперь команда должна запрашивать вновь назначенный пароль. Введите его, и вы должны получить доступ к приглашению базы данных, как ожидалось.

вывод

теперь у вас есть административный доступ к восстановленному серверу MySQL или MariaDB. Убедитесь, что новый пароль root, который вы выбираете, является надежным и безопасным и держит его в безопасном месте.

Источник