DataGrip remote database connections: SSH tunnel versus direct SSL

The decision and your constraints

You need DataGrip to reach a production database that is not on your laptop. The database port may be blocked by a firewall, the server may or may not accept encrypted connections, and you may have access to a bastion host. A bastion host is an intermediary server you can SSH into that has network access to the internal database. The choice is not just about encryption; it is about what network surface you expose and how you verify that the connection actually arrived where you intended.

Useful takeaway: choose an SSH tunnel when the database port stays internal and a bastion host is available. Choose direct SSL/TLS when the database itself accepts encrypted connections and you can validate its certificate. Combine SSH plus SSL only when you need defense in depth and can tolerate the added configuration complexity.

This guide assumes JetBrains DataGrip 2023.x or later and a standard JDBC driver, such as the PostgreSQL driver bundled with DataGrip.

Compare the three supported modes

Mode	Traffic encrypted	Network exposure	Best suited for	Main drawback
Direct SSL/TLS	Database traffic between DataGrip and the database server	Database port reachable from your network	Low-latency access when no bastion host exists	Certificate and trust-store management; port exposure
SSH tunnel	Traffic between DataGrip and the bastion host; database sees local tunnel traffic	Database port remains internal; only bastion SSH port is exposed	Bastion host available, database does not expose SSL	Added hop, single point of failure, possible pooling issues
SSH plus SSL	Both the SSH tunnel and the database connection inside it	Database port internal; bastion mediates access	Defense in depth for highly regulated environments	Highest configuration complexity

Trade-offs to weigh before you configure

Direct SSL/TLS

Direct SSL encrypts the payload, but encryption alone does not prove the server's identity. A trust store is the collection of certificates your client uses to verify a server. If you disable certificate validation, the connection is vulnerable to a man-in-the-middle attack, where an attacker can impersonate the database. You must also manage the server certificate and open the database port to your client network.

SSH tunnel

An SSH tunnel forwards a local port through the bastion host to the database. DataGrip connects to localhost, and the database receives the connection as if it came from the bastion. This avoids exposing the database port, but the tunnel adds latency and depends on the bastion staying reachable. Long-running transactions or ETL jobs can be more fragile because the tunnel is an extra network hop.

SSH plus SSL

This mode encrypts the tunnel and the database session. It is the strongest option in the table, but it requires both SSH credentials and valid database certificates. Debugging connection failures is harder because either layer can reject the session.

Configure a PostgreSQL data source through an SSH tunnel

1. Open DataGrip and open Data Sources and Drivers from the File menu or settings.
2. Click the add button, choose PostgreSQL, and give the data source a name such as production-bastion.
3. On the General tab, enter the database host, port, user, and password. Use the internal database hostname or IP reachable from the bastion, not your local machine.
4. Open the SSH/SSL tab.
5. Select SSH tunnel.
6. Enter the bastion host, SSH port, typically 22, and bastion user.
7. Choose an authentication method: password or private key. If you use a private key, enter the path, for example ~/.ssh/id_ed25519. Enable agent forwarding only if your SSH agent already holds the key and you want DataGrip to use it.
8. Leave SSL settings disabled unless you also want to encrypt the database session inside the tunnel.
9. Click Test Connection. Do not save the data source until the test succeeds.

Verify the connection and check the result

Confirm the tunnel path

Before configuring DataGrip, validate the SSH key from your local terminal. Run:

ssh -i ~/.ssh/id_ed25519 user@ 'echo bastion-reachable'

Where to run: your local terminal, not inside DataGrip. Required permissions: read access to the private key file. Expected check: you reach a bastion shell or see the echoed text. Risk: wrong key, missing permissions, or agent forwarding misconfigured will fail before DataGrip ever tries the database.

After saving the data source, open a query console in DataGrip and run:

SELECT 1;

Expected check: a single row with value 1. To prove the database sees the connection from the bastion, query PostgreSQL session activity:

SELECT application_name, client_addr, state
FROM pg_stat_activity
WHERE datname = '';

Where to run: DataGrip query console or psql connected to the same database. Required permissions: read access to pg_stat_activity, typically available to superusers or roles with monitoring privileges. Expected check: client_addr shows the bastion host address, not your workstation IP. Risk: if your role lacks privileges, the query returns zero rows; that does not prove the tunnel failed.

Confirm encryption when using SSL

If you enable direct SSL or SSH plus SSL, run this in the DataGrip console:

SHOW ssl;

Expected check: on. If the result is off, the session is not encrypted even if the UI shows an SSL checkbox.

Limitations and rollback

Older DataGrip versions may not support agent forwarding or newer key formats such as OpenSSH Ed25519. If the key works in your terminal but DataGrip rejects it, try a different key format or update DataGrip. SSH tunnels can complicate connection pooling; long-running sessions may drop if the bastion restarts or the network blips.

DataGrip may store connection passwords in its password manager. Do not commit IDE project files or data source XML containing plaintext credentials to version control.

Because saving a data source changes IDE state, rollback means opening Data Sources and Drivers, selecting the data source, and removing the SSH tunnel settings or switching the connection back to direct host and port. Test the connection again after reverting.