Reach private databases through SSH, with verified host keys

What it is

Most production databases and Kubernetes API servers aren’t on the public internet. In New connection or Edit connection, tick Connect through SSH tunnel and DevOpsPad reaches the target through a bastion host. This works for every engine: MySQL, Redis, MongoDB, Kafka, ClickHouse, Kubernetes and K3s.

Enter the database host and port as seen from the SSH server — localhost means the bastion’s own loopback. For Kubernetes and K3s, the API server address comes from the selected kubeconfig context.

How it works

• Authentication. A private key file (including encrypted keys with a passphrase, and ~/ paths), an SSH password, or a running SSH agent via SSH_AUTH_SOCK.
• Host key verification. Your ~/.ssh/known_hosts, another known_hosts file you choose, or a SHA256:… fingerprint from your administrator. Unknown or changed keys fail. Nothing is trusted on first use.
• No local listener. Each operation opens a short-lived SSH session, forwards over SSH TCP channels inside the app, and closes the session when it finishes or is cancelled. No port is opened on your machine.
• No silent fallback. If SSH fails, the connection fails; it never retries directly.
• TLS still applies. Database hostname verification is kept, and Kubernetes keeps the kubeconfig’s CA, client certificates and TLS server name. DNS for the target is resolved on the SSH server.
• Separate secrets. Database passwords, SSH passwords and key passphrases each get their own entry in the OS keychain. Private keys stay in their files.

Test connection authenticates to SSH and then runs the engine’s real connectivity check, so a green result means the whole path works.

Kafka and Kubernetes details

Kafka clients connect to the brokers’ advertised addresses after the first request. Those connections also go through the tunnel, so the advertised addresses must be reachable from the SSH server. For Kubernetes, context and namespace discovery, resource details, events and Pod logs all use the same tunnel.

Limits

• Single hop only: no ProxyJump, ProxyCommand or OpenSSH config aliases.
• No keyboard-interactive authentication.
• SSH agent support uses the Unix socket in SSH_AUTH_SOCK. If the desktop app can’t see it, use a key file or password.
• HTTP proxy environment variables and kubeconfig proxy URLs are bypassed for tunneled requests.

See SSH troubleshooting for common errors, and the engineering note on tunnels without a local listener.