С выходом MySQL 8.0 Oracle по умолчанию включила новый плагин аутентификации caching_sha2_password. Он призван улучшить безопасность и ускорить повторные подключения благодаря механизму кэширования. Но на практике многие админы сталкиваются с двумя классическими проблемами: несовместимостью старых клиентов и неполной или неверной настройкой TLS. В результате — ошибки «Public Key Retrieval is not allowed», «Client does not support authentication protocol requested by server», неожиданные отказанные подключения и отключённые шифры.
В этой статье разложим по полочкам, как устроен caching_sha2_password, почему он эффективен только в связке с TLS, как правильно включить шифрование транспорта в mysqld, создать пользователей и мигрировать с mysql_native_password с минимальными рисками. Разберём типовые ошибки и чеклист для продакшена.
Зачем MySQL 8 перешёл на caching_sha2_password
Исторически большинство инсталляций MySQL использовали mysql_native_password — достаточно старый алгоритм со специфичным хешированием пароля. Его главный плюс — совместимость. Минусы — устаревшие криптографические практики и отсутствие механизмов, оптимизирующих повторные подключения.
Плагин caching_sha2_password решает две задачи:
- Использует современные примитивы (SHA-256) для хранения и проверки паролей.
- Ускоряет повторную аутентификацию: сервер кэширует ключ для недавнего клиента и может подтвердить пользователя без передачи всего протокола «с нуля» (меньше RTT при высоконагруженных пулах соединений).
Важно: безопасность
caching_sha2_passwordпредполагает защищённый транспорт. Наилучший вариант — обязательный TLS. Без TLS плагин может прибегать к шифрованию пароля RSA-ключом сервера, но это компромиссный режим, которого лучше избегать.
Как работает аутентификация: с TLS и без
Высокоуровнево процесс выглядит так:
- Если клиент подключается по TLS, пароль пользователя защищён транспортным шифрованием; плагин выполняет обмен с контрольными суммами и возможным использованием кэша на сервере.
- Если TLS нет, сервер может запросить шифрование пароля своей публичной RSA-частью. Клиент должен получить публичный ключ сервера и зашифровать пароль, чтобы он не ушёл в сеть открытым текстом.
Режим без TLS влечёт дополнительные риски и сложности совместимости: не все драйверы готовы автоматически получать публичный ключ, некоторые по умолчанию запрещают его загрузку по соображениям безопасности. Поэтому правильный путь — включать TLS на стороне сервера и заставлять клиентов его использовать.
Совместимость клиентов с caching_sha2_password
Для успешной работы вам понадобятся обновлённые клиенты и коннекторы. Практически безболезненно работают:
- Официальный клиент
mysqlверсии 8.x и библиотекаlibmysqlclient8.x. - MySQL Connector/J 8.0.11+ (Java).
- MySQL Connector/Python 8.x.
- PHP с
mysqlnd8.x: поддерживаетcaching_sha2_passwordпри наличии TLS. - Современные драйверы Go (go-sql-driver/mysql с поддержкой), Node.js (mysql2) — уточняйте в документации версии драйвера.
Если у вас исторические клиенты (PHP 7.0–7.1, старые JDBC/ODBC), они могут не знать о caching_sha2_password. В этом случае используйте один из безопасных сценариев миграции (см. ниже) или обновляйте коннекторы.
Включаем TLS в MySQL 8: базовая схема
Чтобы плагин аутентификации был действительно безопасен, включите TLS и запретите нешифрованные подключения. Минимальный набор шагов:
- Сгенерируйте собственный центр сертификации (CA) и от него — серверный сертификат для
mysqld. Если нет своего PKI, используйте корпоративный CA или приобретите публичные SSL-сертификаты. - Укажите пути к ключам/сертификатам в конфигурации
mysqld. - Ограничьте версии TLS и при необходимости задайте перечень шифров.
- Включите требование защищённого транспорта глобально и/или на уровне пользователей.
Пример фрагмента my.cnf
[mysqld]
ssl_ca=/etc/mysql/ssl/ca.pem
ssl_cert=/etc/mysql/ssl/server-cert.pem
ssl_key=/etc/mysql/ssl/server-key.pem
tls_version=TLSv1.2,TLSv1.3
require_secure_transport=ON
После перезапуска сервера проверьте, что TLS активен:
mysql -u root -p --ssl-mode=REQUIRED -e "SHOW VARIABLES LIKE 'have_ssl';"
mysql -u root -p --ssl-mode=REQUIRED -e "SHOW STATUS LIKE 'Ssl_version';"
В статусе вы должны увидеть версию TLS (например, TLSv1.3). Команда mysql --ssl-mode=VERIFY_IDENTITY дополнительно проверяет имя хоста в сертификате, что актуально для удалённых подключений.
Тонкая настройка TLS
Рекомендуется:
- Оставлять только
TLSv1.2иTLSv1.3вtls_version. - Использовать сертификат с корректным CN и SAN (имена хостов), если клиенты применяют
VERIFY_IDENTITY. - Поддерживать автоматическую ротацию: в MySQL 8 доступна команда
ALTER INSTANCE RELOAD TLSдля подхвата новых сертификатов без остановки.
Создание пользователей с caching_sha2_password
В MySQL 8 плагин caching_sha2_password используется по умолчанию. Вы можете задать его явно и одновременно потребовать TLS для этого пользователя:
CREATE USER 'app'@'10.%' IDENTIFIED WITH caching_sha2_password BY 'StrongP@ssw0rd' REQUIRE SSL;
GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'app'@'10.%';
Если вы используете клиентские сертификаты (mTLS), ужесточите политику:
CREATE USER 'svc'@'%' IDENTIFIED WITH caching_sha2_password BY 'AnotherStr0ng!' REQUIRE X509;
Также доступны точечные ограничения по полям сертификата (например, REQUIRE SUBJECT, REQUIRE ISSUER), что полезно при централизованной PKI.
Глобальные политики безопасности
Две опции помогают сделать шифрование нормой:
require_secure_transport=ON— запрет на незащищённые подключения вообще (клиенты должны использовать TLS или сокеты ОС).- На уровне пользователей —
REQUIRE SSLилиREQUIRE X509, чтобы даже при ослаблении глобальной настройки конкретные учётки оставались защищёнными.
Даже если вы доверяете внутренней сети, включённый TLS спасает от ARP‑spoofing, атак уровней L2/L3, MITM на промежуточных участках и «временных» туннелях, которые порой делают интеграторы.
Когда всё-таки нужен mysql_native_password
Иногда обновление клиентов невозможно быстро. Тогда временно оставляют старый плагин на части пользователей или в качестве дефолта. Оптимальная стратегия — точечно и со сроком, параллельно готовя обновление драйверов.
Перевод конкретного пользователя
ALTER USER 'legacy'@'%' IDENTIFIED WITH mysql_native_password BY 'TmpStrongPass1!';
Временное изменение дефолта (не рекомендуется как постоянная мера)
[mysqld]
default_authentication_plugin=mysql_native_password
После миграции клиентов верните дефолт к caching_sha2_password и перевыпустите пароли унаследованных учёток. Помните, что mysql_native_password — решение ради совместимости, а не ради безопасности.
Типичные ошибки и их устранение
1) Client does not support authentication protocol requested by server
Причина: старый коннектор не поддерживает caching_sha2_password. Решение: обновить драйвер или перевести конкретного пользователя на mysql_native_password временно.
2) Public Key Retrieval is not allowed
Причина: клиент подключается без TLS, сервер требует зашифровать пароль публичным ключом, но драйвер запрещает автоматическую загрузку ключа. Решения:
- Включить TLS и подключаться с
--ssl-mode=REQUIREDили сильнее (рекомендуется). - Либо задать путь к публичному ключу сервера на клиенте и разрешить его использование (меняется опциями драйвера). Но это временная мера, лучше перейти на TLS.
3) Authentication plugin 'caching_sha2_password' reported error
Часто связано с отсутствием TLS, неверным временем на серверах, битым кэшем или failover, после которого кэш недействителен. Проверьте синхронизацию времени (NTP), включён ли TLS, и попробуйте переподключение.
4) TLS ругается на имя хоста
При использовании --ssl-mode=VERIFY_IDENTITY CN/SAN в сертификате сервера должен соответствовать тому имени, к которому обращается клиент. Решение: перевыпустить сертификат с корректными SAN, либо использовать имя, вписанное в сертификат.
Проверка состояния TLS и аутентификации
Полезные команды для диагностики:
SHOW VARIABLES LIKE 'have_ssl';
SHOW VARIABLES LIKE 'tls_version';
SHOW STATUS LIKE 'Ssl_cipher';
SHOW SESSION STATUS LIKE 'Ssl_version';
SHOW PLUGINS;
На стороне клиента проверьте фактический режим:
mysql -u app -p --ssl-mode=VERIFY_IDENTITY -h db.example.internal -e "\s"
В выводе \s будет строка про SSL. Если пусто — клиент не установил защищённое соединение.
Репликация и TLS
Для репликации в 8.0 используйте новую форму команды и включайте TLS для канала:
CHANGE REPLICATION SOURCE TO
SOURCE_HOST='db-master.internal',
SOURCE_USER='repl',
SOURCE_PASSWORD='S3cureRepl!1',
SOURCE_SSL=1,
SOURCE_SSL_CA='/etc/mysql/ssl/ca.pem';
START REPLICA;
Пользователя репликации создавайте с REQUIRE SSL и современным плагином аутентификации. Для построения отказоустойчивости и фейловера пригодится наш материал: GTID, полусинхронная репликация и failover.
RSA-ключи caching_sha2_password: стоит ли трогать
Плагин поддерживает RSA-ключи для сценариев без TLS. Управляющие переменные:
caching_sha2_password_auto_generate_rsa_keys— автогенерация ключей сервером.caching_sha2_password_private_key_path,caching_sha2_password_public_key_path— явные пути к ключам.
Рекомендация проста: не полагайтесь на этот путь. Если вы можете включить TLS, включайте. RSA остаётся лишь «подпоркой» для старых клиентов и изолированных лабораторных стендов.
Производительность: кэш аутентификации
caching_sha2_password хранит кэш аутентификационных данных для недавних клиентов. Это сокращает число раундов при повторном подключении и уменьшает латентность, особенно в микросервисах и пулах соединений. На больших инсталляциях это даёт измеримый выигрыш по CPU и времени ответа, при условии стабильности сети и корректного TTL кэша. Переход на caching_sha2_password вкупе с TLS обычно улучшает метрики handshake по сравнению с mysql_native_password.
Ротация и обслуживание сертификатов
Регулярно ротируйте серверный сертификат и, при использовании mTLS, клиентские. В MySQL 8 можно подхватить новые файлы без даунтайма:
ALTER INSTANCE RELOAD TLS;
Подготовьте процедуру аварийной откатной замены и мониторинг истечения сроков: собирайте метрики или парсите SHOW STATUS, добавьте алертинг по валидности сертификатов базы и приложений. Приватные ключи храните с ограниченными правами и аудитом. Для резервных копий инфраструктуры и ключей посмотрите наш практический обзор инструментов: Бэкапы с restic/borg и S3.
Миграция с mysql_native_password: практический план
- Инвентаризируйте клиентов и драйверы, зафиксируйте версии.
- Включите TLS в MySQL и проверьте режимы
REQUIREDиVERIFY_IDENTITYна тестовом стенде. - Создайте параллельного пользователя с
caching_sha2_password, протестируйте авторизацию с каждого приложения. - Переведите продакшн‑приложения на нового пользователя или смените плагин существующего пользователя через
ALTER USER. - Только если часть клиентов осталась «в каменном веке», временно оставьте им
mysql_native_password, но под жёстким сроком обновления и сREQUIRE SSL. - Удалите или переведите остатки на современный плагин, верните дефолт
caching_sha2_password, проведите ревизию прав и ротацию паролей.
Чеклист настройки продакшена
- TLS включён,
tls_version=TLSv1.2,TLSv1.3. require_secure_transport=ONглобально.- Пользователи с
REQUIRE SSLилиREQUIRE X509. - Сертификаты с корректными SAN, от доверенного CA, расписание ротации + мониторинг.
- Драйверы обновлены; для Java — Connector/J 8+, для PHP —
mysqlnd8+. - Нет пользователей на
mysql_native_passwordбез строгой причины и сроков миграции. - Репликация по TLS, аккаунт репликации с ограниченными правами.
- Бэкапы и утилиты управления (dump/import) тоже подключаются по TLS.
FAQ: коротко о важном
Нужно ли включать TLS, если база только внутри VPC/VLAN?
Да. Сетевые границы часто размыты, а внутренние компрометации — реальны. TLS минимизирует последствия и закрывает MITM.
Что важнее: обновить клиентов или включить TLS?
Начните с TLS. Это даст защиту уже сегодня, а затем планово обновляйте драйверы для полной поддержки caching_sha2_password.
Сломается ли производительность от TLS?
Современные CPU с AES‑NI и TLSv1.3 дают минимальные накладные расходы; выигрыш от кэша аутентификации часто перекрывает этот оверхед. Если уводите базу в отдельную среду, поднимайте её на VDS с гарантированными ресурсами.
Итоги
caching_sha2_password — стандарт для MySQL 8, сочетающий современную криптографию и ускоренное повторное рукопожатие. Его истинная сила раскрывается только в паре с грамотно настроенным TLS. Включите шифрование транспорта, задайте строгие политики на уровне пользователей, обновите клиенты — и аутентификация в MySQL станет и быстрее, и безопаснее. Если же совместимость пока мешает, ограничьте применение mysql_native_password только теми сценариями, где обновление критично задерживается, и обозначьте дедлайны. Контроль версий драйверов, ротация сертификатов и регулярные проверки — ваши лучшие друзья в поддержке устойчивой и безопасной базы данных.
