Built-in SSH tunnel vs OS-level port forwarding for bastion access without persisting production credentials

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?