Support `caching_sha2_password` authentication plugin with Proxy in Unix Socket mode
jackwotherspoon opened this issue · 7 comments
The Cloud SQL Proxy currently does not support the caching_sha2_password authentication plugin when listening over a unix socket.
This is an issue as in MySQL 8.4, caching_sha2_password has now become the default authentication plugin. Any new database users created with the caching_sha2_password will be unable to log in via the Proxy over unix socket.
Failed logins are not always clear that the authentication plugin is the root cause of the issue:
ERROR 1045 (28000): Access denied for user 'my-user'@'cloudsqlproxy~34.124.164.49' (using password: YES)
The Cloud SQL Language Connectors are a viable alternative and workaround at the moment as they work with MySQL 8.4 and the caching_sha2_password plugin:
Hi @jackwotherspoon is there an ETA on a fix for this? We're looking to update our MySQL 5.7 databases to 8.4 but are being blocked by this bug because it's affecting App Engine connections to Cloud SQL. We use PHP so can't use the connector workaround.
is there an ETA on a fix for this? We're looking to update our MySQL 5.7 databases to 8.4 but are being blocked by this bug because it's affecting App Engine connections to Cloud SQL. We use PHP so can't use the connector workaround.
@simon-peek-poke I know the MySQL team is actively working on the fix to this.
Let me reach out and see if they can provide me with an ETA. Will report back 😄
As a workaround connect once with tcp, and then you can connect with sockets.
Another workaround is to connect once with GCP consoles new "Cloud SQL Studio"
daniel@legski:~$ mysql -h 127.0.0.1 --port 3307 -u dantest2 -p
Enter password:
ERROR 2061 (HY000): Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.
daniel@legski:~$ mysql -h 127.0.0.1 --port 3307 -u dantest2 -p --get-server-public-key
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 47942
Server version: 8.4.3-google (Google)
Copyright (c) 2000, 2025, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> exit
Bye
$ mysql -S ~/cloudsql/xxxx\:australia-southeast1\:store-dev2-0-a18cc097 -u dantest2 -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 49911
Server version: 8.4.3-google (Google)
Copyright (c) 2000, 2025, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>
From further research it seems that workaround is only temporary due to some server caching mecahanism.
From further research it seems that workaround is only temporary due to some server caching mechanism.
@dantheperson Yes the caching_sha2_password authentication plugin will cache secure connections for a given period, which is why your workaround works temporarily. However, as you mentioned once the cache entry expires then the full authentication would be required on the next connection attempt.
I have escalated this issue internally to the MySQL team and they are hoping to get the fix out for it ASAP.
Does this issue affect accounts with access via IAM Group authentication, or does it only affect native/built-in database users?
Does this issue affect accounts with access via IAM Group authentication, or does it only affect native/built-in database users?
@dantheperson I believe this issue should only affect native/built-in database users.
IAM database users (IAM user, service account, groups etc.) all go through their own different authentication flow.