Unable to connect to MySQL Workbench from Mac to Ubuntu MySQL 8.0 server, although CLI connection works

Other Questions MySQL
1

I’m facing an issue when trying to connect MySQL Workbench to my MySQL server on an Ubuntu 24.04 machine with MySQL version 8.0. I’m running this from my Mac.

I’ve created a specific user in MySQL with the necessary access rights. The user details are shown below:

SELECT host, user, plugin FROM mysql.user;
+-------------+------------------+-----------------------+
| host        | user             | plugin                |
+-------------+------------------+-----------------------+
| 192.168.1.% | remoteuser      | mysql_native_password |
| localhost   | debian-sys-maint | caching_sha2_password |
| localhost   | mysql.infoschema | caching_sha2_password |
| localhost   | mysql.session    | caching_sha2_password |
| localhost   | mysql.sys        | caching_sha2_password |
| localhost   | root             | auth_socket           |
+-------------+------------------+-----------------------+

When I attempt to connect through MySQL Workbench using the Standard TCP/IP method, I receive the following error:

Failed to Connect to MySQL at 192.168.1.xy:3306 with user remoteuser

However, I can successfully connect to the MySQL server from my Mac using the command line client:

$ mysql -h 192.168.1.xy -u remoteuser -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 33
Server version: 8.0.42-0ubuntu0.24.04.1 (Ubuntu)

Could anyone help me understand why the connection fails in Workbench while it works perfectly in the CLI?

2

Check your workbench connection timeout settings - the default timeout’s usually too short and workbench quits before the handshake finishes. Go to connection settings and bump up the timeout values in the advanced tab. Also clear workbench’s connection cache since it sometimes gets stuck with old connection data.

3

I’ve hit this exact issue before - it’s usually a firewall problem on the Ubuntu box. Your CLI works fine, but Workbench connects differently and might need extra ports open. First, check if ufw is running with sudo ufw status. If it’s active, open MySQL traffic with sudo ufw allow 3306/tcp. Next, make sure MySQL is listening on all interfaces, not just localhost. Run sudo netstat -tlnp | grep 3306 and look for 0.0.0.0:3306 instead of 127.0.0.1:3306. Also worth checking if your router blocks ports between the Mac and Ubuntu machine. Quick test: try telnet 192.168.1.xy 3306 from your Mac to see if the port’s even reachable before Workbench tries to authenticate.

4

I had a similar challenge recently, and it often stems from authentication plugin discrepancies. Even if the CLI connection works flawlessly with mysql_native_password, Workbench can be picky. To resolve this, create your connection in Workbench without connecting and navigate to the Advanced tab. There, include default-auth=mysql_native_password in the Others field. Additionally, verify that your remoteuser’s password doesn’t contain special characters that Workbench might mishandle as compared to the CLI. Lastly, ensure you’re entering the same IP address in both applications, as Workbench can sometimes have hostname resolution issues. If these steps don’t remedy the situation, consult the MySQL error log on the Ubuntu server while attempting to connect via Workbench to identify specific failures.

5

This appears to be an SSL/TLS mismatch between Workbench and your server. I experienced a similar issue when upgrading from MySQL 5.7 to 8.0. MySQL Workbench tries to use SSL by default, while your Ubuntu MySQL 8.0 setup may not have SSL configured properly or is using self-signed certificates. The CLI client is less sensitive to SSL discrepancies. In your Workbench connection settings, access the SSL tab and set ‘Use SSL’ to ‘No’ or ‘If available’. If that doesn’t work, verify the ‘require_secure_transport’ variable on your MySQL server with SHOW VARIABLES LIKE 'require_secure_transport';. If it’s ON, it enforces SSL connections that Workbench might struggle with. Additionally, ensure your server is set to bind to all interfaces by editing /etc/mysql/mysql.conf.d/mysqld.cnf, changing bind-address to 0.0.0.0 instead of 127.0.0.1.

6

Check your MySQL Workbench connection settings against your CLI setup. Workbench sometimes gets confused with cached connections or handles connection strings differently than you’d expect. Delete your existing connection and create a brand new one from scratch. Also check if your Ubuntu MySQL server has skip-name-resolve enabled in the config. This makes MySQL use IP addresses instead of hostnames for auth, which can mess with how Workbench connects compared to CLI. If you’re still stuck, turn on general query logging temporarily to see if Workbench’s connection attempts are even hitting the auth stage. That’ll tell you if it’s a network problem or an authentication issue.