BeziSync

Databases behind a bastion (SSH)

PostgreSQL, MySQL/MariaDB, SQL Server, Oracle, CockroachDB and Vitess connections can reach a database through an SSH bastion (jump host). Open Show expert settings → SSH tunnel on the connection and set the bastion host, port and user, the private key (OpenSSH or PEM, no passphrase; stored encrypted and write-only, or a secret-store reference) and — recommended — the bastion's host key from ssh-keyscan -t ed25519 <bastion>. Host and port stay the database's address as seen from the bastion.

  • Checks, discovery and probes open a short-lived tunnel; the readiness checks report whether the bastion is reachable (*_ssh) and whether the tunnel works (*_ssh_tunnel, a warning while the host key is not pinned).
  • Each connector gets a bezisync tunnel sidecar (Kubernetes: a native sidecar container; Docker: a companion container sharing its network) that keeps the forward open and reconnects; Debezium connects to 127.0.0.1:15432. The bastion must allow TCP forwarding (AllowTcpForwarding yes).
  • TLS still works through the tunnel, but the server name is then 127.0.0.1: use require or verify-ca, not verify-full.
  • MongoDB is not supported (replica-set members announce their own host names); use a network route or an agent runtime inside the network instead. Spanner is a Google API, not a host.
  • Vitess tunnels both VTGate ports: gRPC for the connector, MySQL for the checks.

Edit this page on GitHub