MySQL ERROR 1045 (28000): Access denied for user - diagnosis

When you see ERROR 1045 (28000): Access denied for user 'app'@'10.0.0.5' (using password: YES), the connection never reached the query parser. MySQL rejected it during authentication, incremented Aborted_connects, and returned SQLSTATE 28000. The error always includes the effective user and host as seen by the server. This is your first and most important clue.

This error has four root causes in production: wrong credentials, user@host mismatch, authentication plugin incompatibility, and host-level blocking from accumulated connection errors. A brute-force probe and a misconfigured deploy look identical from the server side, so diagnosis hinges on correlating the error pattern with connection metrics and the host cache.

Do not confuse this with ER_CON_COUNT_ERROR (“Too many connections”). If the server has reached max_connections, the client gets a different error. ERROR 1045 means the TCP handshake succeeded but the server refused the credentials or the source host.

What this means

The error fires after the TCP handshake completes and the server has spawned a connection thread, but before any query executes. MySQL looks up the username against mysql.user, matches the connecting host against the host column (resolving via DNS unless skip_name_resolve is enabled), validates the password against the stored authentication string, and checks the account plugin. Any mismatch returns ERROR 1045 (28000) and increments the global Aborted_connects counter.

If a client IP exceeds max_connect_errors consecutive failed handshakes, the server blocks the host in performance_schema.host_cache. Subsequent attempts from that IP are rejected immediately with a message naming the blocked host. This bypasses password checking entirely. The host cache applies only to remote TCP connections; Unix socket, named pipe, and shared memory connections are exempt.

The user and host in the error message are the server’s view of the connection. If your application host has multiple network interfaces, traverses a NAT gateway, or connects through a pooler, the IP in the error may differ from what you expect. This mismatch is a common source of confusion during incident response.

flowchart TD
    A[ERROR 1045 or host blocked] --> B{Blocked host message?}
    B -->|Yes| C[Check host_cache SUM_CONNECT_ERRORS]
    B -->|No| D{User@host exists?}
    D -->|No| E[Check mysql.user and skip_name_resolve]
    D -->|Yes| F{Plugin mismatch?}
    F -->|Yes| G[Check TLS/RSA or client library]
    F -->|No| H[Check password and credential rotation]

Common causes

Quick checks

Run these safe, read-only checks to classify the failure.

-- Check total failed connection attempts
SHOW GLOBAL STATUS LIKE 'Aborted_connects';

Take two samples 10 seconds apart to compute a rate.

-- Distinguish auth failures from capacity exhaustion
SHOW GLOBAL STATUS LIKE 'Connection_errors_max_connections';

-- Check blocked hosts and per-IP error counts
SELECT IP, HOST, SUM_CONNECT_ERRORS, FIRST_ERROR_SEEN, LAST_ERROR_SEEN
FROM performance_schema.host_cache
WHERE SUM_CONNECT_ERRORS > 0
ORDER BY SUM_CONNECT_ERRORS DESC;

-- Verify the configured error threshold
SHOW GLOBAL VARIABLES LIKE 'max_connect_errors';

-- Check if DNS resolution is disabled
SHOW GLOBAL VARIABLES LIKE 'skip_name_resolve';

-- Verify user existence, allowed hosts, and auth plugin
SELECT user, host, plugin, authentication_string
FROM mysql.user
WHERE user = 'app';

-- Find the error log path
SHOW VARIABLES LIKE 'log_error';

Inspect that file for Access denied entries with source IPs.

-- Check current connections to spot idle or retry loops
SHOW PROCESSLIST;

How to diagnose it

1. Read the exact error message. If it says Host '...' is blocked, skip to host cache analysis. Otherwise, note the user and host; this is the server’s view of the client after any name resolution.
2. Query performance_schema.host_cache. If SUM_CONNECT_ERRORS is at or above max_connect_errors (default 100) for the client IP, the host is blocked. Unblock it with TRUNCATE TABLE performance_schema.host_cache; or FLUSH HOSTS;, then identify the source of the errors before it reblocks.
3. Verify the account exists with a matching host. Run SELECT user, host, plugin FROM mysql.user WHERE user = '...';. If the connecting IP does not match any host column (including wildcards like %), the server rejects the connection with ERROR 1045. Remember that skip_name_resolve=ON disables DNS lookups, and accounts defined with literal hostnames will silently fail to match. If this is the case, recreate the account with an IP literal or %.
4. Check the authentication plugin. If the account uses caching_sha2_password (the default since MySQL 8.0) and the client is old, it may not support the plugin. If the server is MySQL 9.0, mysql_native_password has been removed entirely; any account still using it will fail to authenticate.
5. Check for the caching_sha2_password first-connect trap. After a password change or RENAME USER, the server’s cached entry is cleared. The next connection over unencrypted TCP must use TLS or RSA key exchange. If the client does not pass --get-server-public-key or --server-public-key-path, the connection can fail. Confirm whether the client is configured for TLS.
6. Check for a credential rotation mismatch. Cross-reference the timestamp of the Aborted_connects spike with recent deployments or secret rotations. If 90% of your fleet connects fine but one pod is failing, the old secret is still cached locally.
7. Determine if the pattern is malicious. A single source IP generating hundreds of Aborted_connects per minute is likely brute force. Many distinct source IPs failing with the same user suggests a deployment misconfiguration rather than an attack.

Metrics and signals to monitor

Fixes

Blocked host

If performance_schema.host_cache shows SUM_CONNECT_ERRORS >= max_connect_errors, unblock the host with TRUNCATE TABLE performance_schema.host_cache; or FLUSH HOSTS;. TRUNCATE avoids the RELOAD privilege required by FLUSH HOSTS and clears the entire cache. After unblocking, fix the root cause: reconfigure the health check that is aborting mid-handshake, or firewall the attacking IP. Do not raise max_connect_errors to a large number; that removes the throttle and invites brute-force load.

Wrong credentials or rotation lag

Fix the application configuration or secret store. If you must reset the password to restore service, change it in MySQL and then verify all clients receive the new secret. Tradeoff: a hard password reset bypasses the rotation pipeline and can leave stale secrets elsewhere.

User@host mismatch

If the client connects from an IP that is not in mysql.user, add the correct host literal with CREATE USER or GRANT. If the client IP is dynamic, use a wildcard or subnet. Tradeoff: % is convenient but widens the attack surface. If skip_name_resolve is ON, use IP literals or %; literal hostnames will never match.

Authentication plugin incompatibility

If the client library is recent enough, alter the user to caching_sha2_password. If you cannot upgrade the client and the server version still supports it, you can temporarily use mysql_native_password. On MySQL 9.0, this plugin is removed; the only fix is to upgrade the client or driver. For the RSA key exchange issue with caching_sha2_password, the fix is to require TLS for all connections, which avoids the RSA handshake entirely.

skip_name_resolve interaction

Recreate accounts using IP literals instead of hostnames. Do not disable skip_name_resolve just to fix grants if it was enabled to avoid DNS latency or spoofing risks.

Prevention

• Monitor Aborted_connects rate continuously and correlate spikes with deployment markers.
• Keep max_connect_errors at 100 or lower; treat blocks as signals, not obstacles.
• Use TLS for every client connection. This eliminates the caching_sha2_password RSA key exchange failure mode and prevents credential exposure.
• Audit mysql.user for deprecated plugins before any upgrade to 8.4 or 9.0.
• When skip_name_resolve is enabled, maintain grants with IP literals or %. Avoid hostname-based grants entirely.
• Rotate credentials through a canary instance first, and watch Aborted_connects before rolling out fleet-wide.

How Netdata helps

• Charts Aborted_connects and Aborted_clients rates, surfacing auth failure spikes without manual polling.
• Correlates Aborted_connects spikes with deployment annotations on the timeline.
• Surfaces performance_schema.host_cache metrics per source IP to warn when a legitimate client is approaching max_connect_errors.
• Cross-references MySQL connection saturation with Connection_errors_max_connections to separate access-denied incidents from connection-exhaustion incidents.

Related guides

• How MySQL actually works in production: a mental model for operators
• MySQL Aborted_connects and Aborted_clients climbing: diagnosis
• MySQL adaptive hash index latch contention: high CPU, low throughput
• MySQL binary logs filling the disk: expiry, lagging replicas, and purge
• MySQL InnoDB buffer pool hit ratio collapse: the cliff edge
• MySQL slow after restart: buffer pool warm-up and the cold cache
• MySQL innodb_buffer_pool_size tuning: 60-80% of RAM and when that breaks
• MySQL Innodb_buffer_pool_wait_free > 0: buffer pool memory pressure
• MySQL InnoDB checkpoint age: the redo log capacity signal nobody watches
• MySQL connection exhaustion: detection, diagnosis, and prevention
• MySQL innodb_deadlock_detect=OFF: when deadlock detection becomes the bottleneck
• MySQL ERROR 1213: Deadlock found when trying to get lock; try restarting transaction