MySQL/MariaDB: аутентификация по UNIX‑сокету

Инструкция по настройке входа в MySQL или MariaDB без пароля через локальный UNIX‑сокет с привязкой к системному пользователю. В статье учтены различия между MySQL 8.x и MariaDB 10.4+, приведены готовые команды, проверки, диагностика, чек‑листы, а также рекомендации по эксплуатации на продакшене.

Что такое «аутентификация по сокету» и когда её применять

Идея: сервер БД доверяет удостоверению ОС‑пользователя локальной машины. Если имя ОС‑пользователя совпадает (или явно смэплено) с именем БД‑пользователя, вход разрешается без пароля по локальному сокету mysqld.sock.

Когда уместно:

Локальная админка/CI на том же хосте, где крутится БД.
Системные задачи (бэкапы, миграции, Ansible/cron), когда секреты хранить нежелательно.

Когда лучше не использовать в одиночку:

Доступ по сети (TCP/127.0.0.1/::1/удалённо) — сокет здесь не работает; используйте пароли/ключи/TLS и минимум привилегий.

Ключевые различия MySQL vs MariaDB

MySQL 8.x: плагин называется auth_socket. Допускается явное соответствие ОС‑юзера: IDENTIFIED WITH auth_socket AS 'osuser'.
MariaDB 10.4+: плагин называется unix_socket. Поддерживаются составные методы: IDENTIFIED VIA unix_socket OR ed25519 USING PASSWORD('…') и пр.

Внимание: синтаксис различается — не путайте auth_socket (MySQL) и unix_socket (MariaDB).

Расположение сокета и доступ

Типовой путь в Debian/Ubuntu: /var/run/mysqld/mysqld.sock (часто владельцем каталога является группа mysql).
Убедитесь, что ваш ОС‑пользователь имеет доступ к каталогу и сокету (через группу/права). Иногда достаточно добавить пользователя в группу mysql и перелогиниться.
В контейнерах/Docker путь может отличаться; пробросьте сокет томом, либо используйте TCP.

Проверка на клиенте:

mysql_config --socket  # если установлен
# или
mysql --print-defaults | tr ' ' '\n' | grep -i socket

MySQL 8.x — настройка шаг за шагом

Создайте/проверьте ОС‑пользователя

# пример: системный пользователь 'deploy'
sudo adduser --disabled-password --gecos "" deploy
# при необходимости добавьте в группу mysql для доступа к каталогу сокета
sudo usermod -aG mysql deploy

Подключитесь под админом и создайте БД‑пользователя

-- Вариант A: имя БД‑пользователя = имя ОС‑пользователя
CREATE USER 'deploy'@'localhost' IDENTIFIED WITH auth_socket;
GRANT ALL ON appdb.* TO 'deploy'@'localhost';

-- Вариант B: сопоставление с иным ОС‑логином (например, 'ci')
CREATE USER 'deploy'@'localhost' IDENTIFIED WITH auth_socket AS 'ci';
GRANT ALL ON appdb.* TO 'deploy'@'localhost';

Тест входа

# должен выполняться от имени соответствующего ОС‑пользователя
sudo -u deploy mysql -u deploy -S /var/run/mysqld/mysqld.sock -e "SELECT USER(),CURRENT_USER();"

Ожидаемо USER() покажет ОС‑сеанс, CURRENT_USER() — учетную запись MySQL (deploy@localhost).

Проверки

SELECT user, host, plugin FROM mysql.user WHERE user='deploy';
SHOW VARIABLES LIKE 'socket';
SHOW PLUGINS LIKE 'auth_socket';

MariaDB 10.4+ — настройка шаг за шагом

ОС‑пользователь

sudo adduser --disabled-password --gecos "" deploy
sudo usermod -aG mysql deploy

БД‑пользователь c unix_socket

-- Чистая аутентификация через сокет
CREATE USER deploy@localhost IDENTIFIED VIA unix_socket;
GRANT ALL ON appdb.* TO deploy@localhost;

-- Комбинированная аутентификация (альтернативы)
-- Разрешим вход по сокету ИЛИ по паролю для сетевых подключений
CREATE USER admin@'%' IDENTIFIED VIA unix_socket OR ed25519 USING PASSWORD('S3cret!');
GRANT ALL ON *.* TO admin@'%' WITH GRANT OPTION;

Тест и проверки

sudo -u deploy mysql -u deploy -S /var/run/mysqld/mysqld.sock -e "SELECT USER(),CURRENT_USER();"

-- В MariaDB 10.4+ привилегии хранятся в таблице mysql.global_priv
SELECT user, host FROM mysql.global_priv WHERE user='deploy';
SHOW VARIABLES LIKE 'socket';

Политика для root и админ‑доступов

На Ubuntu/Debian root@localhost часто по умолчанию использует сокет‑аутентификацию. Не переводите root на пароль ради удалённого доступа.
Для удалённой админки создайте отдельного суперпользователя: ограничьте хосты ('admin'@'10.0.%'), включите TLS и регулярно ревизуйте привилегии.

Типовые роли и паттерны эксплуатации

Локальные сервисные учётки (backup/rotate/etl): сокет‑аутентификация, минимальные привилегии на нужные БД.
Приложения по TCP: отдельные аккаунты с паролем/сертификатами, ограниченные хосты, TLS, принцип минимально необходимых прав.
CI/CD: локальный пользователь ci + IDENTIFIED WITH auth_socket AS 'ci' (MySQL), либо чистый unix_socket (MariaDB) + гранты только на схему приложения.

Диагностика и устранение неполадок

Симптом: Access denied при входе без пароля.

Вы действительно запустили клиент от верного ОС‑пользователя? Проверьте whoami и используйте sudo -u <user>.
Клиент соединяется именно по UNIX‑сокету, а не по TCP? Добавьте -S /path/to/mysqld.sock.
Есть ли у пользователя доступ к каталогу сокета (ls -ld /var/run/mysqld)? Добавьте в группу mysql и перелогиньтесь.
На MySQL проверьте, что плагин auth_socket активен и назначен аккаунту (SELECT user,host,plugin FROM mysql.user).
На MariaDB проверьте IDENTIFIED VIA unix_socket у нужного аккаунта.

Симптом: «Не видит» сокет или «No such file or directory».

Уточните путь сокета через SHOW VARIABLES LIKE 'socket'; и используйте его в mysql -S ….
Если сервер запущен в контейнере — пробросьте сокет томом или подключайтесь по TCP.

Симптом: Вошёл «не тот пользователь»/привилегий слишком много.

Проверьте CURRENT_USER() — именно он участвует в проверке привилегий.
Уточните гранты: SHOW GRANTS FOR 'deploy'@'localhost'; и сократите лишнее.

Безопасность

Принцип наименьших привилегий: на сокетных аккаунтах давайте только необходимые SELECT/INSERT/UPDATE/….
Аудит: логируйте административные действия (general log/slow log/инструменты SIEM).
Секреты: не сохраняйте пароли там, где достаточно сокета, но документируйте соответствие имён (кто к кому маппится).
SELinux/AppArmor: убедитесь, что профили разрешают доступ к сокету для нужных пользователей/служб.

Чек‑лист

Перед настройкой

Понимание: сокет работает только локально, по TCP не применяется.
Знаете точный путь сокета и права на каталог.
Созданы необходимые ОС‑пользователи; определены роли и границы привилегий.

Настройка

Для MySQL: CREATE USER … IDENTIFIED WITH auth_socket [AS 'osuser'].
Для MariaDB: CREATE USER … IDENTIFIED VIA unix_socket (при необходимости — составные методы).
Выданы минимально необходимые привилегии на схемы.

Проверка

Вход sudo -u <user> mysql -u <dbuser> -S <sock> успешен.
CURRENT_USER() совпадает с ожидаемой учеткой БД.
Гранты соответствуют принципу наименьших прав.

Эксплуатация

Задокументировано сопоставление ОС↔БД пользователей.
У админ‑учеток по сети — TLS и ограниченные хосты.
Включён аудит/логирование.

Частые вопросы (FAQ)

Можно ли оставить root на сокете, а для удалёнки завести admin@'%'? — Да, это рекомендуемый путь. Root по сокету, отдельный суперпользователь для сети.
Можно ли «и сокет, и пароль»? — В MariaDB да (составные методы). В MySQL — создайте пару учеток (сокет для локала, парольная для сетевых задач) либо используйте конкретное сопоставление AS 'osuser'.
Почему mysql -u user просит пароль? — Вы запускаете не от того ОС‑пользователя; либо клиент ушёл по TCP. Добавьте -S и/или используйте sudo -u <os_user>.

Итог

Аутентификация по UNIX‑сокету упрощает и укрепляет локальную работу с MySQL/MariaDB: не нужно хранить пароли, снижается риск утечек, повышается управляемость. Главное — правильно разделять роли, понимать различия между MySQL и MariaDB, удостовериться в доступе к сокету и документировать соответствия пользователей. Такой подход отлично сочетается с автоматизацией и строгой моделью привилегий на продакшене.