SSH Tunnel vs Direct JDBC in DataGrip: Portable Connection Choice

Short answer

For a single data‑source definition that works on a developer’s laptop, a CI agent, and a support machine, use a direct SSL‑enabled JDBC connection and keep all machine‑specific details (SSH host, local port, private keys) out of the XML. Externalize secrets via environment variables or the IDE’s credential store, and keep the truststore path in the shared definition. If exposing the database port is not acceptable, keep the SSH tunnel but establish it externally (e.g. with ssh -L or an ~/.ssh/config entry) so the XML remains identical.

Why that works

• SSH tunnels bound to localhost are inherently machine‑specific; the port number and host travel with the XML and break on any machine that can’t reach the bastion.
• DataGrip supports environment variables in the data‑source URL and the IDE’s native password store, so secrets can stay out of the project file.
• Direct JDBC over SSL requires the database port to be reachable from every environment, which is a trade‑off that can be mitigated with tight security‑group rules or IP allowlists.
• When using SSL, you can enforce certificate verification by setting the driver’s sslmode (e.g. verify-ca or verify-full) and pointing to a trusted CA bundle.
• A hybrid approach—keep the XML direct‑JDBC‑only and let each machine run its own ssh -L command—lets you avoid exposing the port while still sharing a single XML.

Practical steps for a portable XML

1. Export the data‑source definition (File → Export Data Sources). Verify the XML does not contain any sshHost, localPort, or plaintext credentials.
2. Configure the JDBC URL to use ssl=true (or the driver‑specific flag) and point to the database’s public endpoint. Example for PostgreSQL: jdbc:postgresql://db.example.com:5432/mydb?sslmode=verify-full&sslrootcert=/path/to/ca.crt.
3. Externalize secrets:
   • Use environment variables in the URL: jdbc:postgresql://$DB_HOST:$DB_PORT/$DB_NAME?sslmode=verify-full&sslrootcert=$CA_PATH.
   • Store the password in DataGrip’s credential store (File → Passwords). The XML will reference a placeholder that the IDE resolves at runtime.
4. Verify on two machines:
   • Import the same XML on a developer laptop and a CI agent.
   • Attempt a connection. If it fails, check that both machines are using the same driver version (DataGrip bundles a driver per project; ensure the Driver section is identical).
   • Run a quick test against a host with a self‑signed certificate and confirm the connection is rejected, proving SSL verification is active.
5. Security review:
   • Confirm the database port is allowed in the security group for the CI agent’s IP range.
   • Ensure the truststore contains only the CA that issued the database certificate.
   • If the port cannot be opened, set up a per‑machine ssh -L command and keep the XML unchanged; document the command in the project README.

What to ask next

To decide whether to expose the DB port or keep an SSH tunnel, we need one key detail:

What firewall or security‑group rules currently allow traffic to the database port from your CI agents’ IP ranges?

Answering that will confirm if the direct‑SSL approach is feasible or if the hybrid SSH‑tunnel strategy is required.