On OCI, a common layout puts the WordPress server in a public subnet and MySQL in a private subnet. MySQL in the private subnet can’t be reached directly from the internet, so you need a separate path for administration. This post shows how to use the WordPress server you already reach over SSH as a jump host, and connect to MySQL through a PuTTY SSH tunnel.
At a glance
- Path: your PC
127.0.0.1:3307→ (SSH 22) WordPress server → (3306) MySQL private IP - Ports open to the internet: only the existing SSH (22). MySQL 3306 stays closed to the outside.
- What you need: PuTTY, a
.ppkprivate key, the MySQL private IP, and a security rule that allows 3306 - Effort: once those are ready, four PuTTY settings
Setting up WordPress on OCI is covered in Set Up WordPress on OCI ARM, and the MySQL HeatWave database in WordPress Database Optimization with MySQL HeatWave. I first published this on a separate blog in September 2025 and re-checked the facts as of October 2026 when moving it here.
Which approach to use
An SSH tunnel takes connections arriving at a local port on your PC, carries them inside the SSH connection to the WordPress server, and the WordPress server hands them to MySQL on port 3306. There are three ways to get the same result. Prices and limits are from Oracle’s official information as of October 2026 and may change, so check again before you rely on them.
| Approach | Extra cost | Session length | Good fit when |
|---|---|---|---|
| WordPress server as jump host (this post) | None (existing server) | No limit (while SSH stays connected) | You already manage a public server over SSH |
| OCI Bastion service | None (free per Oracle’s price list) | Up to 3 hours per session | You want a managed access path without a public server |
| Dedicated bastion VM | VM cost (0 within Always Free) | No limit | Several people need a dedicated access server |
Note: With a jump host, SSH access to the WordPress server becomes the way into the database. Manage that server’s SSH keys and allowed source IPs more strictly.
What you need
| Item | Details |
|---|---|
| PuTTY | Download it from the official PuTTY page. |
| WordPress server login | Public IP and SSH user (usually opc on Oracle Linux images) |
| SSH private key | PuTTY uses the .ppk format. Convert a .pem/OpenSSH key from OCI with PuTTYgen: Load, then Save private key. |
| MySQL details | Private IP (for a DB System, the endpoint shown in the console) and a database user |
| Security rule | The security list or NSG on the MySQL subnet must allow TCP 3306 from the WordPress server’s private IP (or subnet). |
Four PuTTY settings
Step 1. Session
On the Session screen, enter:
- Host Name:
opc@<WordPress_public_IP> - Port:
22 - Connection type: SSH
Step 2. Private key
Under Connection → SSH → Auth → Credentials, set “Private key file for authentication” to your converted .ppk file. The menu location can differ slightly between PuTTY versions.
Step 3. Tunnel
Under Connection → SSH → Tunnels, enter the values below and click Add.
- Source port:
3307 - Destination:
<MySQL_private_IP>:3306 - Direction: Local
If MySQL is installed on your PC, port 3306 may already be in use, so the example uses 3307.
Step 4. Keepalive and save
Setting “Seconds between keepalives” on the Connection screen to about 30 reduces dropped idle connections. Go back to the Session screen, enter a name under Saved Sessions (for example, wp-mysql-tunnel), click Save, and then Open.
Tip: The tunnel works only while this PuTTY window is open. Next time, load the saved session and click Open.
Connect to MySQL
With the PuTTY window open, point your local MySQL client at the local port. Use 127.0.0.1 rather than localhost so the client connects over TCP instead of a socket.
mysql -h 127.0.0.1 -P 3307 -u <DB_user> -pOnce connected, confirm you reached the remote server. You should see the remote server’s host name and version, not your local MySQL.
SELECT @@hostname, @@version;
SHOW DATABASES;In MySQL Workbench, create a connection with Hostname 127.0.0.1, Port 3307 and your database user. Workbench’s own “Standard TCP/IP over SSH” connection method builds the same path without PuTTY.
Security checklist
| Target | Check |
|---|---|
| SSH (22) | Allow only the sources you need, such as administrator IPs |
| MySQL (3306) | Allow only from the WordPress server’s private IP or subnet; never open it to the internet (0.0.0.0/0) |
| Private key | Protect it with a passphrase and keep it where only your account can read it |
| Database user | Grant only the privileges needed; use a separate read-only account for queries |
| After work | Close the PuTTY window to end the tunnel; don’t put passwords on the command line or in scripts |
Diagnosing connection problems layer by layer (security rules, host firewall, service listener) is covered in OCI Connectivity Diagnosis.
When it doesn’t connect
| Symptom | Check first |
|---|---|
| PuTTY can’t reach the server | Public IP, allowed sources for port 22, .ppk key path. The problem is before the tunnel. |
| Connection refused / Lost connection in the MySQL client | Whether the PuTTY window is open, the Destination IP and port under Tunnels, and whether MySQL’s security rule allows 3306 from the WordPress server |
| Access denied | Database user and password, and whether that user may connect from the WordPress server’s IP (or %) |
| Tunnel port can’t be opened | Whether another program already uses 3307 on your PC (netstat -ano | findstr :3307). You can switch to another port. |
You can check whether the WordPress server reaches the MySQL port by logging in to it over SSH. MySQL HeatWave DB System is a managed service, so you can’t log in to the database host to check the service; check its status in the OCI console.
# Run on the WordPress server: check the 3306 connection
timeout 3 bash -c '</dev/tcp/<MySQL_private_IP>/3306' && echo "3306 open" || echo "3306 closed"Summary
If you already manage a WordPress server, one PuTTY SSH tunnel lets you reach the database in the private subnet without opening the MySQL port to the outside. In exchange, the WordPress server’s SSH becomes the path to the database, so manage its keys and allowed IPs more strictly. If you have no public server, or want access history managed in OCI, consider the free OCI Bastion service.
