Debian/Ubuntu: MySQL ERROR 1045 Access denied for user — причины и исправление

Инструкции
01 апр, 2026
Время на чтение: ~16 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

Ошибка MySQL ERROR 1045 (28000): Access denied for user — одна из самых частых проблем при подключении к MySQL и MariaDB на Debian и Ubuntu. Внешне она выглядит одинаково, но причины почти всегда разные: неверный пароль, неправильный пользователь, неподходящий host, смена плагина аутентификации, попытка войти под root не тем способом или старые реквизиты в конфиге приложения.

Хорошая новость в том, что в большинстве случаев проблему можно исправить без переустановки сервера и без опасных манипуляций с системными таблицами. Главное — сначала понять, в каком именно месте сервер отказывает: на уровне пользователя, источника подключения или способа аутентификации.

На Debian и Ubuntu это особенно важно, потому что локальный вход для root часто настроен не по паролю, а через Unix socket. Из-за этого администратор может быть уверен, что «пароль сломался», хотя на деле парольный вход для этой учётной записи просто не используется.

Что на самом деле означает ERROR 1045

Ошибка 1045 означает, что сервер MySQL принял попытку подключения, распознал имя пользователя, но не разрешил аутентификацию. Это не сетевая ошибка и не признак того, что служба не запущена. Если бы проблема была в сокете, порте или самой службе, сообщение было бы другим.

Обычно в тексте ошибки уже есть ключ к разгадке:

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
ERROR 1045 (28000): Access denied for user 'appuser'@'localhost' (using password: YES)
ERROR 1045 (28000): Access denied for user 'root'@'127.0.0.1' (using password: YES)

Здесь важно смотреть не только на имя пользователя, но и на часть вида 'user'@'host'. Для MySQL это полноценная пара, а не просто подпись в сообщении. Учётные записи 'root'@'localhost' и 'root'@'127.0.0.1' могут вести себя по-разному.

Самая частая ошибка при диагностике — сосредоточиться на слове root и пропустить, что отказ приходит для другого host: 127.0.0.1, имени контейнера или удалённого IP.

С чего начать проверку

Сначала убедитесь, что сервер вообще работает и проблема действительно в авторизации:

sudo systemctl status mysql
sudo systemctl status mariadb
sudo ss -ltnp | grep 3306
mysqladmin ping

На разных системах служба может называться mysql или mariadb. Если демон активен, проверьте способ подключения — через сокет и через TCP отдельно:

mysql -u root
mysql -u root -p
mysql -u root -p -h localhost
mysql -u root -p -h 127.0.0.1

Если один вариант работает, а другой нет, это уже сильно сужает круг причин. localhost часто означает вход через Unix socket, а 127.0.0.1 — TCP-подключение по loopback.

Если вы разворачиваете базу на отдельном сервере или под приложение, которому нужен изолированный доступ и предсказуемая среда, удобнее использовать VDS: там проще контролировать версии MySQL, сокеты, firewall и параметры аутентификации.

Почему на Debian и Ubuntu часто не пускает root

После стандартной установки MySQL или MariaDB пользователь root нередко привязан к системной аутентификации через Unix socket. В MySQL это обычно auth_socket, в MariaDB — unix_socket. Это означает, что локальный системный root может войти без SQL-пароля, если запускает клиент через sudo.

Из-за этого появляются два типичных сценария:

администратор запускает mysql -u root -p, хотя парольная аутентификация для SQL-пользователя root не настроена;
приложение пытается использовать root по TCP, хотя такая схема входа для него не разрешена.

Самая быстрая проверка — попробовать локальный вход так:

sudo mysql
sudo mariadb

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

Как посмотреть user, host и plugin

После входа в консоль проверьте существующие учётные записи:

SELECT user, host, plugin FROM mysql.user ORDER BY user, host;

Эта команда отвечает сразу на три вопроса:

какие пользователи реально существуют;
с каких хостов им разрешён вход;
какой плагин аутентификации они используют.

Например, вы можете увидеть root@localhost с auth_socket, но не найти root@127.0.0.1. Или обнаружить, что пользователь приложения создан как appuser@localhost, а само приложение подключается как appuser@127.0.0.1.

Это как раз тот случай, когда полезно сначала навести порядок в схеме доступа, а уже потом менять пароли и конфиги.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Проблема №1: неверная пара user и host

В MySQL и MariaDB связка user + host критична. Ошибка Access denied может означать не плохой пароль, а то, что для конкретного источника подключения нет подходящей записи.

На практике чаще всего встречаются такие варианты:

localhost — обычно локальный сокет;
127.0.0.1 — TCP по loopback;
имя контейнера — в Docker или другой внутренней сети;
конкретный внутренний IP — если приложение и база на разных серверах;
% — любой хост, если это явно разрешено.

Посмотреть все записи для нужного пользователя можно так:

SELECT user, host FROM mysql.user WHERE user='appuser';

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

CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'StrongPasswordHere';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'localhost';
FLUSH PRIVILEGES;

Если приложение реально подключается по TCP к 127.0.0.1, нужна отдельная запись:

CREATE USER 'appuser'@'127.0.0.1' IDENTIFIED BY 'StrongPasswordHere';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'127.0.0.1';
FLUSH PRIVILEGES;

Именно на этом месте часто ломаются проекты после миграции: старый сервер использовал сокет, а новый стек, контейнер или orchestration — TCP.

Проверка пользователей, host и plugin в MySQL или MariaDB

Проблема №2: неподходящий auth plugin

Ещё одна частая причина — пользователь существует, пароль выглядит правильным, но клиент не умеет работать с текущим методом аутентификации. В MySQL 8 по умолчанию часто используется caching_sha2_password, а старые драйверы рассчитывают на mysql_native_password. Для локального root на Debian и Ubuntu обычно задействован auth_socket или unix_socket.

Проверка простая:

SELECT user, host, plugin FROM mysql.user WHERE user='root';
SELECT user, host, plugin FROM mysql.user WHERE user='appuser';

На проблему с плагином обычно указывают такие симптомы:

после обновления сервера старое приложение перестало входить в базу;
из консоли mysql вход проходит, а из PHP, Python или Java — нет;
ошибка проявляется только на одной машине со старой библиотекой клиента;
в таблице mysql.user указан неожиданный plugin.

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

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH mysql_native_password BY 'StrongPasswordHere';
FLUSH PRIVILEGES;

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

Если у вас сложная MySQL-инфраструктура с репликацией и переключением ролей, полезно отдельно изучить материал про GTID, semi-sync и failover в MySQL: там хорошо видно, почему единый и понятный подход к пользователям и аутентификации критичен не только для приложений, но и для обслуживания кластера.

Проблема №3: MariaDB access denied после изменения root

В MariaDB типовой сценарий такой: администратор меняет пароль root, затем пытается войти как раньше, а учётная запись всё ещё работает через unix_socket. В итоге создаётся впечатление, что пароль не применился или сервер игнорирует изменения.

Здесь важно не смешивать два подхода:

локальный вход администратора через системную учётную запись и sudo;
парольный вход SQL-пользователя.

Оба варианта допустимы, но нужно выбрать один основной сценарий и не пытаться использовать root одновременно как системного администратора и как прикладную учётную запись.

Для приложений давать root вообще не стоит. Гораздо надёжнее создать отдельного пользователя с минимальными правами на конкретную базу.

Как восстановить доступ безопасно

Если вы всё ещё можете войти через sudo mysql или sudo mariadb, это лучший вариант. Изнутри сервера можно спокойно исправить пользователя, пароль, host и метод аутентификации без запуска базы в специальных режимах.

Например, вместо использования root можно создать отдельного администратора:

CREATE USER 'dbadmin'@'localhost' IDENTIFIED BY 'StrongAdminPasswordHere';
GRANT ALL PRIVILEGES ON *.* TO 'dbadmin'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;

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

CREATE USER 'siteuser'@'localhost' IDENTIFIED BY 'StrongAppPasswordHere';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP ON site_db.* TO 'siteuser'@'localhost';
FLUSH PRIVILEGES;

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

Если база используется в продакшене, а приложение развёрнуто в типовой shared-среде, заранее учитывайте ограничения платформы и способ подключения к БД. Для простых проектов это удобно на виртуальном хостинге, а для полной управляемости параметрами аутентификации чаще выбирают отдельный сервер.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Если не пускает даже через sudo mysql

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

Базовый набор команд для диагностики:

sudo journalctl -u mysql -n 100 --no-pager
sudo journalctl -u mariadb -n 100 --no-pager
sudo grep -R "socket" /etc/mysql
mysql --print-defaults
sudo ls -l /run/mysqld
sudo ls -l /var/run/mysqld

Здесь цель простая: понять, к какому сокету пытается подключаться клиент, где реально запущен сервер и не перепутаны ли сервисы, конфиги и пакеты.

Диагностика сокета и конфигурации MySQL на сервере Linux

Где ещё искать причину: конфиг приложения

Если из консоли вход работает, а сайт или сервис всё равно получает ERROR 1045, проблема часто находится не в сервере, а в конфиге приложения. Проверьте:

имя пользователя в .env, config.php, wp-config.php и системных переменных;
точный хост подключения: localhost или 127.0.0.1;
старый пароль в unit-файлах systemd, контейнерных переменных или секретах CI/CD;
наличие пробелов, кавычек и неверно экранированных спецсимволов;
совпадение сокета в конфиге приложения с реальным сокетом сервера.

Хороший практический приём — взять те же параметры, что использует приложение, и вручную выполнить вход из shell. Если ручной вход не работает, проблема точно в реквизитах или способе подключения. Если работает — смотрите драйвер, окружение процесса и формат секрета.

Если дальше планируете резервное копирование и восстановление после ошибок в продакшене, полезно держать под рукой и сценарии point-in-time recovery. По теме пригодится статья про восстановление MySQL и MariaDB через binlog и GTID.

Короткий алгоритм устранения ERROR 1045

Проверьте, что служба MySQL или MariaDB запущена.
Сравните вход через сокет и через TCP.
Попробуйте sudo mysql или sudo mariadb.
Посмотрите user, host и plugin в mysql.user.
Уточните, откуда реально приходит клиент: localhost, 127.0.0.1, контейнер, внутренний IP.
Создайте или исправьте точную учётную запись под этот сценарий.
Проверьте совместимость клиента с текущим плагином аутентификации.
Только после этого обновляйте пароль и конфиги приложения.

Чего делать не стоит

При ошибке 1045 администраторы часто усугубляют ситуацию одними и теми же действиями:

используют root в приложениях вместо отдельного пользователя;
создают доступ 'user'@'%' без реальной необходимости;
меняют плагин аутентификации вслепую;
смешивают инструкции для MySQL и MariaDB без проверки версии;
редактируют системные таблицы вручную там, где достаточно CREATE USER или ALTER USER;
пытаются лечить проблему переустановкой пакетов.

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

Вывод

Ошибка MySQL ERROR 1045 Access denied for user на Debian и Ubuntu — это не одна поломка, а целая группа ситуаций вокруг аутентификации. Обычно всё сводится к одному из четырёх факторов: неверный пароль, неправильная пара user/host, неподходящий plugin или попытка использовать root не тем способом, который предусмотрен в системе по умолчанию.

Практически всегда правильная стратегия одна и та же: сначала определить способ подключения, затем проверить записи в mysql.user, после этого сверить plugin и только потом вносить изменения. Для приложений используйте отдельного пользователя с ограниченными правами, а локальное администрирование на Debian и Ubuntu удобнее и безопаснее вести через sudo mysql, если это соответствует вашей схеме.

Поделиться статьей