Using DBeaver’s Built‑in SSH Tunnel to Connect to Remote Databases Securely

Problem: Exposing a database port directly is often unsafe or impossible

Many organizations keep database servers behind firewalls or in private subnets. Opening a port to the outside world for a client tool like DBeaver creates a security risk, and VPNs may not be available for every workstation. You need a way to reach the remote database without altering network policies or installing extra software.

Thesis: DBeaver’s SSH tab creates an encrypted tunnel that forwards a local port to the remote database, letting you work as if the database were local

By configuring the SSH settings once, DBeaver establishes a tunnel whenever you open the connection, encrypts the traffic with SSH, and presents the remote database as a localhost endpoint. This works for all DBMS types DBeaver supports and persists across sessions.

Section 1: Configuring the SSH tunnel

1. In DBeaver, choose Database → New Connection and select your DBMS.
2. Fill in the usual host, port, database name, and credentials for the target database.
3. Switch to the SSH tab.
4. Enable Use SSH tunnel.
5. Enter the SSH gateway host (the machine you can reach that has network access to the database).
6. Provide the SSH username.
7. Choose authentication: either password or a private‑key file (click … to browse). If you use a key, ensure the file is readable by your user.
8. Optionally, set a specific Local port; leaving it blank lets DBeaver pick an available port automatically.
9. Click Test Connection. DBeaver will attempt to negotiate the SSH session and then connect to the database through the tunnel.

If the test succeeds, you will see a message like "SSH tunnel established" followed by a successful database authentication.

Section 2: Using the tunnel in daily work

Once the connection is saved, you can treat it like any other DBeaver connection:

• Open the SQL editor and run queries; the traffic flows over the SSH tunnel.
• Use the data grid, ER diagram designer, or debugging tools without extra configuration.
• Disconnect and reconnect later; DBeaver automatically re‑establishes the SSH tunnel using the stored settings.

Section 3: Trade‑offs and practical checks

Performance impact

The only overhead is the SSH encryption and decryption. Latency is dominated by the round‑trip time between your workstation and the SSH gateway; DBeaver adds negligible processing time.

Port‑conflict risk

If you manually set a local port that another DBeaver instance or another tool already uses, you will get an "address already in use" error. The safest approach is to leave the Local port field blank, allowing DBeaver to select a free port each time.

Verification steps you can perform

1. After a successful Test Connection, open the SQL editor for that connection.
2. Run a simple statement such as SELECT 1 AS test;.
3. If the query returns a result row, the tunnel is correctly forwarding traffic to the remote database.
4. To verify persistence, disconnect the connection (right‑click → Disconnect) and then reconnect; you should not need to re‑enter SSH details.

Closing: When to choose this approach

Use DBeaver’s built‑in SSH tunnel when you have reliable SSH access to a gateway host and want to avoid opening database ports or managing a separate VPN client. It provides a quick, repeatable way to work securely with remote databases while keeping the client‑side setup minimal. If you lack SSH gateway access or need to multiplex many tunnels with strict port requirements, consider a dedicated SSH client or VPN solution instead.