Securing Database Access with DBeaver SSH Tunneling

The Problem: Exposed Database Ports

Exposing a database port (like 5432 for PostgreSQL or 3306 for MySQL) directly to the public internet is a significant security risk. Even with strong passwords, you invite brute-force attacks and vulnerability scanning. The standard engineering solution is to place the database in a private subnet and use a Bastion Host (or Jump Server)—a hardened server that acts as the sole entry point into the private network.

The friction occurs when developers have to manually manage SSH tunnels via the command line before opening their database GUI. DBeaver solves this by integrating the SSH tunnel directly into the connection lifecycle, meaning the tunnel opens when you connect to the database and closes when you disconnect.

Configuring the Tunnel Architecture

In DBeaver, the SSH tunnel is not a separate connection but a transport layer for your database connection. When configured, DBeaver creates a local port forward on your machine. It sends database traffic through an encrypted SSH pipe to the bastion host, which then forwards that traffic to the database server's internal IP address.

Step-by-Step Implementation

To set up a secure tunnel, follow these steps within the Connection Settings window:

1. Database Main Tab: Enter the internal IP address or hostname of the database server as it is known to the bastion host (e.g., db-internal.vpc.internal). Do not use the public IP here.
2. SSH Tab: Check the box Use SSH Tunnel.
3. SSH Host: Enter the public IP or DNS of your bastion host.
4. Authentication: Select your method. For production environments, Private Key is the standard. Point DBeaver to your .pem or .ppk file. If the key is encrypted, provide the passphrase.
5. Local Port: Leave this as 0 to allow DBeaver to pick an available random port, or specify a fixed port if you have specific local firewall restrictions.

Concrete Example: AWS RDS via EC2 Bastion

Consider a scenario where an RDS instance is in a private subnet and an EC2 instance is in a public subnet. The configuration would look like this:

Setting	Value	Context
DB Host	rds-prod.cluster-cxyz.us-east-1.rds.amazonaws.com	Internal DNS resolved by Bastion
SSH Host	bastion.company.com	Publicly accessible Jump Server
SSH User	ec2-user	OS user on the Bastion host
Auth Method	Private Key	Path to id_rsa or key.pem

Verification and Diagnostics

To verify the tunnel is functioning correctly, click Test Connection. If it fails, check these common failure points:

• Key Format: DBeaver supports OpenSSH and PuTTY formats. If you receive an "Invalid private key" error, ensure the key is not in a proprietary format that requires an external agent.
• Security Groups: Ensure the Bastion host allows inbound SSH (Port 22) from your IP, and the Database server allows inbound traffic from the Bastion host's internal IP on the database port.
• Local Bindings: If you specified a fixed local port, ensure no other application is using that port on your workstation.

Trade-offs and Limitations

While convenient, SSH tunneling introduces specific constraints:

• Latency: Every packet must be encrypted, sent to the bastion, decrypted, and forwarded. This adds overhead to large data exports.
• Single Point of Failure: If the bastion host goes down, all database access is severed, regardless of the database's health.
• Audit Gaps: Database logs will show the connection originating from the Bastion host's IP, not your local workstation's IP, which can complicate forensic auditing.

Closing Action

To secure your workflow, migrate your connection settings from direct public access to SSH tunneling. Once configured, verify the setup by attempting to connect; if successful, you can safely update your database security group to reject all traffic except that originating from your bastion host.