Connect through an SSH tunnel

Every connection type in DevOpsPad can run through an SSH server: MySQL, Redis, MongoDB, Kafka, ClickHouse, Kubernetes and K3s. In the connection dialog, check Connect through SSH tunnel, enter the SSH server, user and authentication method, and keep the database Host and Port as they are seen from the SSH server.

There is no ssh -L to run and no local port to manage. DevOpsPad opens an authenticated SSH session for each operation, forwards TCP through SSH channels inside the app, and closes the session when the operation finishes or is cancelled.

Set up a tunnel

1. Open New connection or Edit connection.
2. Enter the database Host and Port as reachable from the SSH server. localhost means the SSH server’s own loopback interface, which is right when the database runs on the bastion itself. For Kubernetes and K3s, the target is the API server in the selected kubeconfig context.
3. Check Connect through SSH tunnel.
4. Enter SSH host, SSH port (usually 22) and SSH username.
5. Choose SSH authentication:
   • Private key: see private key authentication.
   • Password: see password authentication.
   • SSH Agent: see SSH Agent authentication.
6. Leave Known hosts file empty to use ~/.ssh/known_hosts, choose another file, or enter a trusted Host key fingerprint. See verify host keys.
7. Click Test connection. It authenticates to SSH and then runs the engine’s real check through the tunnel.
8. Click Save connection.

An open connection that uses a tunnel shows · SSH tunnel in its header.

How it behaves

• One session per operation. Opening a table, running a query or loading logs each opens a short-lived session; reads within one operation share it.
• No local listener. Forwarding happens through in-process SSH channels. Nothing else on your machine can use the tunnel.
• DNS on the server side. The target host name is resolved by the SSH server, so internal names such as db.internal work.
• No fallback. If SSH fails, the request fails. DevOpsPad never silently tries a direct connection.
• Proxies bypassed. HTTP proxy environment variables and kubeconfig proxy URLs are ignored for tunneled requests.
• TLS stays end to end. TLS is verified against the database host, not the SSH server; for Kubernetes, against the kubeconfig CA and server name. See TLS options.
• Kafka brokers too. Connections to brokers advertised in Kafka metadata also go through the tunnel, so those addresses must be reachable from the SSH server.

Limits

• Single hop only. ProxyJump, ProxyCommand and chained bastions are not supported.
• ~/.ssh/config is not read: host aliases, IdentityFile, IdentityAgent and similar settings must be entered in the dialog.
• Keyboard-interactive authentication (for example one-time codes) is not supported.
• TCP only.

If a tunnel does not work, see SSH troubleshooting.

Frequently asked questions

Do I need to run ssh -L before connecting?

No. DevOpsPad opens the tunnel itself for each operation and closes it afterwards. It does not open a local listening port.

Does DevOpsPad fall back to a direct connection if SSH fails?

No. When a connection is configured with an SSH tunnel, every request goes through SSH. If the tunnel cannot be opened, the request fails.