Public Key Retrieval Not Allowed: Explained

Here’s an article detailing “Public Key Retrieval Not Allowed”:

The error message “Public Key Retrieval Not Allowed” is a common security-related indicator that arises when a client application attempts to establish a secure connection using public-key cryptography, but the server or client settings explicitly prevent the automatic retrieval or exchange of the necessary public key. While the exact phrasing is most frequently encountered in the context of database connections, similar underlying security principles apply to other systems utilizing public-key infrastructure, such as SSH/Git.

This article will delve into the primary scenarios where this error occurs, its causes, and the recommended solutions.

1. Primary Context: MySQL JDBC Connections

This is by far the most common scenario for encountering the precise “Public Key Retrieval Not Allowed” error. It typically affects Java applications utilizing a JDBC driver to connect to MySQL databases, especially versions 8.0 and newer.

Explanation of Occurrence:

The error stems from changes in MySQL’s security defaults and the way modern JDBC drivers interact with them:

Secure Connections (SSL/TLS): When useSSL=true is specified in the JDBC connection URL, the client expects to establish a secure, encrypted connection. This process often involves the client retrieving the server’s public key to facilitate the encryption handshake.
RSA-based Password Authentication: MySQL 8.0 and later versions introduced caching_sha2_password as the default authentication plugin. This plugin leverages RSA key pairs for a more secure password exchange process. If a client attempts to connect to a user configured with this plugin without an encrypted connection, it may attempt to retrieve an RSA public key from the server for secure password transmission.
Default Security Setting: By default, MySQL servers are configured to disallow automatic public key retrieval. This is a crucial security measure designed to prevent potential vulnerabilities where an attacker could intercept or manipulate the public key retrieval process, leading to compromised connections.

Common Causes:

Incompatible Driver/Server Versions: Using newer JDBC drivers (like MySQL Connector/J 8.0+) with recent MySQL server versions that have enhanced security features enabled by default.
Unencrypted Connections Requiring RSA: The application is attempting to connect to a MySQL user authenticated with caching_sha2_password (the default in MySQL 8+) over an unencrypted connection. The client then tries to retrieve the server’s RSA public key to securely send the password.
SSL/TLS Handshake Issues: While useSSL=true is specified, the client cannot retrieve the server’s public certificate or key required for the SSL handshake, often due to server configuration or network issues.

Resolution Strategies:

Allow Public Key Retrieval (with caution):
The most straightforward, but potentially less secure, solution is to add allowPublicKeyRetrieval=true to your JDBC connection URL.
Example:
jdbc:mysql://localhost:3306/mydb?allowPublicKeyRetrieval=true&useSSL=false
While this resolves the error, it’s generally not recommended for production environments over an unencrypted connection, as it can expose the connection to man-in-the-middle attacks.
Disable SSL (if not required):
If SSL is not strictly necessary for your environment, or if you’re working in a development setting, you can explicitly disable it by adding useSSL=false to the connection URL.
Example:
jdbc:mysql://localhost:3306/mydb?useSSL=false
Be aware that disabling SSL means your connection will not be encrypted, which is unsuitable for transmitting sensitive data.
Change MySQL User Authentication Plugin:
For MySQL users configured with caching_sha2_password, you can change their authentication plugin to the older, but still widely used, mysql_native_password.
SQL Command:
ALTER USER 'your_user'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password';
FLUSH PRIVILEGES;
This might be a viable option for legacy applications or where caching_sha2_password is causing compatibility issues, but caching_sha2_password is generally more secure.
Proper SSL Configuration (Recommended for Production):
For production environments, the most secure approach is to properly configure and enable SSL/TLS on both the MySQL server and the client application. This involves:
1. Generating valid SSL certificates for your MySQL server.
2. Configuring the MySQL server to use these certificates.
3. Configuring your JDBC client to trust these certificates (e.g., by importing the server’s public certificate into the client’s trust store).
  This ensures an encrypted connection without needing to relax security settings like allowPublicKeyRetrieval=true.

2. Related Context: SSH/Git Connections

While the exact “Public Key Retrieval Not Allowed” message is rare here, related issues often manifest as “Permission denied (publickey)” when using SSH (e.g., with Git, SCP, or direct shell access). This signifies a failure in public-key authentication.

Explanation of SSH Key Pairs:

SSH authentication relies on a pair of cryptographic keys:

Private Key: Kept secret on the client machine and never shared.
Public Key: Shared with the remote server.

When a client attempts to connect, the server uses the stored public key to challenge the client. The client then proves its identity by responding with information that can only be generated using its corresponding private key.

Common Causes of “Permission denied (publickey)”:

Public Key Not Registered: The client’s public key has not been added to the authorized_keys file on the remote server (or to the service like GitHub/GitLab).
Private Key Not Loaded: The private key is not loaded into the SSH agent on the client machine, or the client is trying to use the wrong private key.
Incorrect Permissions: Incorrect file permissions on the .ssh directory or the authorized_keys file on the server, or on the private key file on the client. SSH is very strict about permissions for security reasons.
Incorrect Configuration: The SSH client configuration (~/.ssh/config) or server configuration (/etc/ssh/sshd_config) is incorrect, preventing public key authentication.

Resolution Strategies:

Generate and Add SSH Key:
1. Generate an SSH key pair on your client machine (e.g., ssh-keygen).
2. Copy the public key (usually ~/.ssh/id_rsa.pub or ~/.ssh/id_ed25519.pub) to the remote server’s ~/.ssh/authorized_keys file or add it to your profile on services like GitHub/GitLab.
Add Key to SSH Agent:
Ensure your private key is loaded into the SSH agent:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa (or your private key path)
Verify Permissions:
Correct permissions are crucial for SSH keys. On the server:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
On the client, ensure your private key file has chmod 600.
Check SSH Configuration:
Review ~/.ssh/config on the client and /etc/ssh/sshd_config on the server to ensure public key authentication is enabled and paths are correct. Restart the SSH service on the server after modifying sshd_config.

General Security Implications

The reason systems like MySQL, by default, disable automatic public key retrieval is rooted in security best practices. Allowing arbitrary public key retrieval, especially over an unencrypted channel, could create a vulnerability:

Man-in-the-Middle (MITM) Attacks: An attacker could intercept the request for a public key and provide their own, leading the client to encrypt data with the attacker’s key, which the attacker can then decrypt.
Information Leakage: Even if not directly exploitable for MITM, making public keys easily retrievable might expose information about the server’s cryptographic setup.

Conclusion

The “Public Key Retrieval Not Allowed” error, or its SSH counterpart “Permission denied (publickey),” highlights a fundamental aspect of secure communication: the careful and controlled exchange of cryptographic keys. While convenience might tempt developers to relax security settings (like allowPublicKeyRetrieval=true), understanding the underlying causes and implementing proper secure configurations—such as robust SSL/TLS or correctly set up SSH keys—is paramount for maintaining the integrity and confidentiality of your systems and data. Always prioritize the most secure resolution appropriate for your environment.