SSH tunnels

A connection can go through an SSH server, often called a bastion or jump host. Recern opens the tunnel when it connects and closes it when the connection closes.

Settings

Setting	Notes
SSH host and port	Port 22 by default.
User	The user on the SSH server.
Authentication	Password, Key file (with its passphrase, if any) or SSH agent.

The database host and port are then resolved from the SSH server, so localhost means the SSH server itself.

Host keys

Recern checks the SSH server's host key before sending anything:

• Keys in your ~/.ssh/known_hosts are accepted. Recern only reads that file.
• The first time Recern meets an unknown server, it shows the key's fingerprint and asks whether to trust it. Trusted keys are saved in Recern's own known_hosts file.
• If a server's key has changed, Recern refuses to connect and names the file and line with the old key. Remove that line if the change is expected.

TLS through a tunnel

PostgreSQL, MySQL, Microsoft SQL Server, ClickHouse, Cassandra, Qdrant and OpenSearch connections can use TLS through a tunnel: the certificate is still checked against the database host name.

ClickHouse, Qdrant and OpenSearch HTTPS through SSH requires a DNS hostname for the database. The optional CA certificate is read on the computer running Workspace.

Cassandra also verifies the original database host while using only the forwarded endpoint; cluster discovery does not open connections outside the tunnel.

Redis and MongoDB do not support database TLS through SSH in 1.0.0. Use a direct TLS connection when end-to-end database encryption is required. An SSH connection without database TLS encrypts traffic only as far as the SSH server; the remaining database connection must be on an appropriately trusted network.