DBeaver SSH tunnel vs PostgreSQL JDBC sslmode: independent layers or silent override?

Direct answer

Yes. SSH tunnel establishment and PostgreSQL JDBC sslmode are independent configuration boundaries in DBeaver. Host-key verification is an SSH client check that happens before any JDBC socket is opened. sslmode controls TLS between the JDBC driver and the PostgreSQL server as seen by the driver, which with a tunnel is the local forwarded port to the SSH client process.

SSH host-key verification failures abort the tunnel before JDBC sslmode is evaluated. A disabled host-key policy does not override sslmode, but it silently weakens the whole connection: the tunnel can be MITM’d at the SSH layer, so an sslmode=require connection inside a compromised tunnel is not trustworthy.

Encryption mapping with a tunnel:

• Remote network leg client → SSH server: encrypted by SSH, integrity bound to host-key verification.
• Local loopback leg JDBC → local forwarded port: plaintext or TLS depending on sslmode.
• Inside the tunnel SSH server → PostgreSQL server: the TCP stream is carried inside SSH; any JDBC TLS is layered on top of that stream.

Confirmed facts

• SSH tunnel creation precedes JDBC connection. DBeaver opens the SSH session, negotiates host-key verification, and binds the local forward. Only after the forward is ready does DBeaver open the JDBC socket to localhost.
• sslmode is a PostgreSQL JDBC driver property. With a tunnel the driver address is localhost and the port is the local forward. The driver therefore applies sslmode to traffic between the driver and the SSH client process, which is then encapsulated by SSH to the remote host.
• Host-key policy and sslmode do not override each other. Disabling host-key verification leaves the SSH layer vulnerable to MITM while sslmode can still be require/verify-full inside the tunnel.

Likely explanation, version dependent

DBeaver UI merges SSH and database settings, which can create the impression of a single security toggle. In practice the tunnel and JDBC are separate processes. Available SSH host-key policies, encrypted key and agent support, and the exact JDBC parameter names depend on DBeaver edition and version, so confirm in your installed build.

Common risk pattern: sslmode=disable with a tunnel is often assumed safe because "the tunnel is encrypted". That is true for the network path, but the data is plaintext on the local loopback and only SSH provides confidentiality. Local packet capture on loopback can see it.

Minimal verification steps for this case

1. In DBeaver, open the connection → SSH tab. Note host-key policy, e.g., Strict, Accept once, or Ignore. Note authentication method.
2. Open the connection → Driver properties / JDBC URL. Note sslmode value: disable, allow, prefer, require, verify-ca, verify-full.
3. Check PostgreSQL server logs for the incoming connection. An SSL connection is logged as "... SSL connection"; non-SSL is logged without it.
4. Optional loopback check: capture localhost traffic to the forwarded port. Plain PostgreSQL protocol is visible with sslmode=disable; with sslmode=require you will see TLS handshake first.

Assumption: you are using DBeaver’s built-in SSH tunnel with a PostgreSQL JDBC driver connecting to localhost. If your remote PostgreSQL server requires SSL, sslmode=require will still succeed inside the tunnel, but the server will see the connection as originating from the SSH server.

One diagnostic detail that changes the recommendation: what sslmode is actually set in the JDBC driver properties for this connection, and whether the remote PostgreSQL server enforces SSL. If sslmode is disable and you rely solely on SSH, ensure host-key verification is Strict and the SSH host key is pinned. If you need end-to-end TLS validation inside the tunnel, use sslmode=verify-full with a valid server cert and keep SSH host-key verification strict.