Question
Built-in SSH tunnel vs OS-level port forwarding for bastion access without persisting production credentials
Ari River
0 reputation · 05 Apr 2021, 07:51 UTC
128.8K views1
Loading…
0 reputation · 05 Apr 2021, 07:51 UTC
Goal is to test an integration to a remote database behind a bastion host without exposing production ports and without storing production credentials in DBeaver connection settings. Testing should use non-production credentials only.
DBeaver offers a built-in SSH tunnel configured in the connection editor that is created and closed with the database connection. An alternative is external SSH port forwarding managed outside DBeaver, with DBeaver pointed at localhost. DBeaver persists connection parameters including SSH authentication details in local credential storage, which may be protected by a master password but remains readable by the DBeaver process.
Uncertainty remains about credential persistence, tunnel lifecycle separation, key format support, and concurrent connection behavior. DBeaver SSH support uses JSch, which can differ from OpenSSH in supported key formats and algorithms. Tunnel sharing or duplication for concurrent database connections is also unclear.
Which approach keeps SSH private key passphrase and database password out of DBeaver persisted metadata for a bastion constraint? Does the built-in tunnel reuse a single SSH session for multiple database connections within the same workspace? What differences in key format support between DBeaver JSch and OpenSSH affect testing with non-production keys?
35275 reputation · 05 Apr 2021, 14:33 UTC
To keep SSH private key passphrases and database passwords out of DBeaver's persisted metadata, use OS-level port forwarding. In this configuration, DBeaver is pointed at localhost and remains entirely unaware of the bastion host, the SSH keys, and the authentication process.
The primary difference lies in where the authentication handshake occurs and where the resulting configuration is stored.
| Feature | Built-in SSH Tunnel (JSch) | OS-Level Forwarding (OpenSSH) |
|---|---|---|
| SSH Key Path | Stored in DBeaver metadata | Not stored in DBeaver |
| Key Passphrase | Stored in DBeaver credential store | Managed by SSH agent/OS |
| DB Password | Stored if "Save password" is checked | Stored if "Save password" is checked |
| Tunnel Lifecycle | Tied to DB connection | Independent OS process |
DBeaver's built-in tunnel implementation typically creates a separate SSH session for each database connection. It does not automatically multiplex multiple database connections through a single shared SSH session within the workspace. Conversely, an OS-level tunnel is a single persistent process that can serve any number of concurrent database connections.
DBeaver utilizes the JSch library, which has stricter requirements than modern OpenSSH. JSch often fails to recognize the newer BEGIN OPENSSH PRIVATE KEY format. To use built-in tunnels, keys must often be converted to the legacy PEM format:
dbeaverssh-keygen -p -m PEM -f ~/.ssh/id_rsaOS-level forwarding avoids this entirely by using the system's native OpenSSH client, which supports all modern key types (Ed25519, etc.) and formats.
ssh -L 5432:remote-db-host:5432 user@bastion-hostlocalhost and the Port is 5432.Missing Diagnostic Detail: Are you using a hardware security module (HSM) or a specific SSH agent (like Pageant or ssh-agent)? This would further reinforce the need for OS-level forwarding, as JSch cannot natively interface with all external agent providers.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.