Understanding MySQL 8.0 caching_sha2_password Authentication and RSA Key Usage

When using MySQL 8.0.15 replication, the I/O thread may remain in the connecting state if the replication user relies on the caching_sha2_password authentication plugin but the master is not configured with master_ssl=1 , causing a non‑encrypted connection without RSA key configuration.

1. caching_sha2_password plugin

1.1 Purpose: Implements SHA‑256 based authentication.

1.2 How it works: The plugin caches a hash of the username and password; on subsequent connections it matches against the cache for fast authentication, otherwise it validates against the mysql.user table and creates a new cache entry.

1.3 Advantages over sha256_password: Faster second‑login authentication due to server‑side caching, supports RSA‑based password exchange regardless of the SSL library, and works with Unix socket and shared‑memory clients.

1.4 Cache management: Cache entries are cleared when a user is dropped, renamed, password changed, or authentication method altered; FLUSH PRIVILEGES clears all entries; the cache is also cleared on server shutdown.

1.5 Limitations: Users authenticated with caching_sha2_password must connect either via an encrypted SSL/TLS connection or via a non‑encrypted connection that supports RSA key‑based password exchange.

2. Using RSA key pairs with caching_sha2_password

2.1 Key generation: Automatic generation is enabled by default through the caching_sha2_password_auto_generate_rsa_keys variable, which creates a public/private RSA pair at server startup. Manual generation can be performed with mysql_ssl_rsa_setup to create SSL certificates and RSA keys in a specified directory.

2.2 Viewing the RSA public key: The server variable Caching_sha2_password_rsa_public_key reveals the RSA public key used by the authentication plugin.

2.3 Usage considerations: Clients that possess the server's RSA public key can perform RSA‑based password exchange. By default the server does not send the RSA public key; clients must either copy the key file from the server or request the key during connection. Copying avoids extra network round‑trips and is marginally more secure, while requesting the key is more convenient when network security is assured.

2.4 Command‑line client options: To use a copied RSA public key, specify --server-public-key-path on the client command line. To request the key from the server, use --get-server-public-key . The former option is generally preferred over the latter.