Introduction

Granting remote MySQL access is a two-part task: MySQL must allow a user from a non-local host, and the server itself must accept incoming connections on port 3306. Many setups fail because only one side is configured.

Create or Update a User for a Remote Host

In MySQL, accounts are identified by both user name and host. That means 'appuser'@'localhost' is a different account from 'appuser'@'192.0.2.10' or 'appuser'@'%'.

The safest pattern is to create a user for a specific host:

CREATE USER 'appuser'@'203.0.113.25' IDENTIFIED BY 'strong_password_here';
GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'appuser'@'203.0.113.25';
FLUSH PRIVILEGES;

If you truly need access from anywhere, % is the wildcard host:

CREATE USER 'appuser'@'%' IDENTIFIED BY 'strong_password_here';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'%';
FLUSH PRIVILEGES;

Use % cautiously. It is convenient for testing and risky for production unless network controls are strong.

Make MySQL Listen for Remote Connections

Even with the right grants, MySQL may still listen only on the loopback interface. Check the MySQL configuration file, often one of these:

• '/etc/mysql/mysql.conf.d/mysqld.cnf'
• '/etc/mysql/my.cnf'
• '/etc/my.cnf'

Look for bind-address. For broad remote access, it is often set like this:

[mysqld]
bind-address = 0.0.0.0

Then restart MySQL:

sudo systemctl restart mysql

or on some systems:

sudo systemctl restart mysqld

If the server should accept connections only on one private interface, use that IP instead of 0.0.0.0.

Open the Network Path

MySQL user grants are not enough if the operating system firewall or cloud firewall blocks the port. On Linux with ufw, for example:

sudo ufw allow from 203.0.113.25 to any port 3306 proto tcp

In cloud environments, also check security groups, VPC firewall rules, or managed database network policies.

You can confirm the server is listening with:

ss -ltn | grep 3306

Test From the Remote Machine

From the client machine, try:

mysql -h db.example.com -u appuser -p appdb

If the connection fails, the error message is usually informative:

• 'Access denied points to account, host, or password issues.'
• 'Can't connect points to networking, bind address, or firewall issues.'

Treat those as different classes of problem.

Prefer Principle of Least Privilege

Avoid GRANT ALL PRIVILEGES ON *.* unless the account truly needs server-wide administration. Application accounts usually need only a limited set of privileges on one database.

A tighter production grant looks like this:

GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'appuser'@'203.0.113.25';

This keeps remote compromise from turning into full-server compromise.

Common Pitfalls

The most common mistake is granting privileges to 'user'@'localhost' and expecting remote clients to use that account. Host is part of the account identity.

Another problem is using the correct grant but leaving bind-address on 127.0.0.1. In that case MySQL is not reachable from outside the host at all.

Developers also forget the firewall layer. MySQL can be configured correctly and still remain unreachable because the network blocks 3306.

Finally, avoid exposing a remote MySQL port to the public internet unless you have no better option. A VPN, bastion host, SSH tunnel, or private network is usually safer.

Summary

• Remote MySQL access requires both a matching 'user'@'host' account and an open network path.
• Create the remote user explicitly with CREATE USER and GRANT.
• Configure MySQL to listen on the right interface with bind-address.
• Open port 3306 only for trusted source addresses when possible.
• Prefer least-privilege grants and private network access over wide-open exposure.