Remote MySQL Connection: Secure External Access to Your Hosting Database

In short: A remote MySQL connection means connecting to the MySQL or MariaDB database on your hosting account or server from an application that does not run on the same server, such as a reporting tool in your office or a desktop database client. The key to doing it safely is simple: do not open the database port to the whole internet, limit access to one IP address and only the privileges that are needed, and encrypt the traffic with TLS or an SSH tunnel.

Power BI, Excel, an accounting integration or an application on another server may need the data in your website's database. This article explains how remote access works, which method fits which situation and which security steps you should not skip when you open the connection.

What is a remote MySQL connection and when do you need one?

A website usually connects to its database from the same server, through localhost. With a remote connection the client is on another machine and reaches the database server over the network, by default on TCP port 3306. Typical reasons are:

• Reporting and business intelligence: reading sales or order data regularly with a tool such as Power BI.
• Admin tools: inspecting tables with a desktop database client.
• Integration: an application on another server reading or writing the same data.
• Migration: moving data from an old server to a new one.

Your engine may be MySQL or MariaDB. The connection logic is largely the same for both; if you are curious about the differences, read our MySQL vs MariaDB article.

Why is the database closed to the outside by default?

According to MariaDB's remote client access guide, many installations only listen for local connections: the configuration contains bind-address = 127.0.0.1 or skip-networking, which turns off network listening completely. This is a deliberate security choice. A database port that is open to the internet becomes a direct target for password guessing and software vulnerabilities.

Remote access needs three layers to be set up together: the database must listen on a network interface, the user must be allowed to log in from that address, and the server and network firewalls must allow the traffic. If one of them is missing, the connection fails. If all of them are opened wider than necessary, the connection works but the risk grows.

Which method should you choose: direct connection or SSH tunnel?

There are two common methods:

• SSH tunnel: the database port stays closed. The client first connects to the server over SSH and the database traffic travels inside that encrypted connection. It is the safest and easiest option for desktop clients and occasional work.
• Direct connection (IP restricted): port 3306 is opened only to one fixed IP address and the connection is encrypted with TLS. It may be needed for an always-on reporting or integration service that cannot use an SSH tunnel.

On shared hosting plans, whether remote database access is available and how it is allowed depends on the service. If you are not sure, ask first by opening a support ticket before you change anything. On a VPS or server you can follow the steps below yourself.

How do you set up a remote MySQL connection with an SSH tunnel?

You need SSH access to the server for this method. If SSH is new to you, start with our guide what is SSH and how to connect; using an SSH key instead of a password makes it more secure.

1. Open the tunnel: run the command below on your own computer. The -L option of ssh forwards connections to port 3307 on your computer to port 3306 on the server itself.

ssh -L 3307:127.0.0.1:3306 user@server-address

2. Point the client to the local port: while the tunnel is open, enter 127.0.0.1 as the host and 3307 as the port in your database client. From the command line you can connect like this:

mysql -h 127.0.0.1 -P 3307 -u report -p

3. Close the tunnel: close the SSH session when you are done, so access is only open for as long as you need it.

With this method the database still listens only for local connections. The only door visible from outside is SSH, and you protect it with a key.

If you need a direct connection, how do you open it safely?

If an always-on service needs a direct connection, follow this order:

1. Set the listening address: in the database configuration, change bind-address to the network address you want the server to be reached on and remove skip-networking if it is there. Then restart the database service.
2. Tie the user to one IP address: in MySQL and MariaDB, accounts have the form 'user'@'host'. Write the allowed address explicitly and do not use the '%' wildcard. In the example below, 203.0.113.10 is an address reserved for documentation:

CREATE USER 'report'@'203.0.113.10' IDENTIFIED BY 'a-strong-password';
GRANT SELECT ON sales.* TO 'report'@'203.0.113.10';

3. Grant only what is needed: use GRANT to limit privileges to one database and one kind of operation. If the reporting tool only reads, SELECT is enough. Do not use the site's own admin account for remote access.
4. Encrypt the connection: configure TLS for client and server connections and force the account to use it:

ALTER USER 'report'@'203.0.113.10' REQUIRE SSL;

5. Allow only that address in the firewall: open port 3306 only to the client's IP address, not to everyone. For how such rules work, see our guide what is a firewall.

What should you check if the remote connection does not work?

• The connection times out: usually the firewall or the bind-address setting is stopping the traffic.
• Access denied error: you reach the server but the user and address do not match. Make sure the public IP address of the client is the same as the address in the account.
• It works for a while and then stops: the client's IP address may have changed. If your office connection has no fixed IP address, an SSH tunnel is a better fit.

What should you watch after opening remote access?

Delete remote accounts you no longer use, change passwords regularly and watch the database logs for unexpected login attempts. A separate user for reporting also lets you close only that account if something goes wrong. Remote access makes data usable, but it does not replace backups; for a regular backup plan see our backup strategy article.

To sum up: use an SSH tunnel when you can; if a direct connection is required, tie the account to one IP address and the minimum privileges, require TLS and allow only that address in the firewall.

Frequently Asked Questions