Troubleshoot SSH tunnel errors

Start with Test connection and read which layer the error names. Problems fall into four groups: reaching the SSH server, trusting its host key, authenticating, and forwarding from the SSH server to the target. The message tells you which one, and the fix is almost always in the connection dialog or on the bastion.

DevOpsPad never falls back to a direct connection, so a working tunnel is required for every request on that connection.

1. Cannot reach the SSH server

Cannot reach SSH host: … means the TCP connection to SSH host:SSH port failed within 5 seconds.

• Check the host name, the port and whether you need a VPN.
• Enter only a host name or IP in SSH host, without user@ or ssh://; the username has its own field.
• Try nc -vz bastion.example.com 22 from Terminal.

2. Host key not trusted

SSH host key verification failed or does not match the configured fingerprint: see verify host keys.

3. Authentication failed

SSH connection failed: ssh: handshake failed: ssh: unable to authenticate means the server rejected the credentials.

• Check SSH username; it is often ubuntu, ec2-user or your own login, not the database user.
• Private key: make sure the public key is in authorized_keys and the passphrase is correct. See private key authentication.
• Password: the server may have password logins disabled. See password authentication.
• Agent: run ssh-add -l. See SSH Agent authentication.
• Servers that require keyboard-interactive or one-time codes are not supported.

4. Forwarding to the target failed

SSH forwarding to db.internal:3306 failed: … means SSH worked, but the SSH server could not open a connection to the target within 5 seconds.

• Host and Port are resolved and connected from the SSH server. Test from the bastion: nc -vz db.internal 3306.
• localhost means the bastion itself.
• The server may forbid forwarding: check AllowTcpForwarding in sshd_config.

Kafka works for metadata but not for a topic

Kafka clients first ask the bootstrap broker for metadata, then connect to each broker’s advertised address. DevOpsPad sends those connections through the tunnel too, so every advertised address must be resolvable and reachable from the SSH server. If brokers advertise addresses only valid inside a container network, fix advertised.listeners or tunnel through a host inside that network. See Kafka topics and partitions.

TLS errors through a tunnel

TLS is verified against the database Host you entered, not the SSH host. If you enter an IP address or localhost but the certificate is issued for db.example.com, verification fails. Enter the name that is in the certificate; the SSH server resolves it. See TLS options.

For Kubernetes, the kubeconfig’s CA, client certificates and TLS server name are used unchanged, and the API server address from the kubeconfig must be reachable from the SSH server.

Proxies

HTTP proxy environment variables and kubeconfig proxy-url settings are ignored for tunneled connections. If your setup relies on an HTTP proxy to reach the API server, a tunneled connection will bypass it.

Not supported

Setup	Status
Multiple hops, ProxyJump, ProxyCommand	Not supported; single hop only
~/.ssh/config host aliases and options	Not read; enter values in the dialog
Keyboard-interactive or OTP	Not supported
Windows OpenSSH agent pipe, Pageant	Not supported; use a key file

Still stuck

Confirm the same path works with OpenSSH from Terminal, replacing the values with yours:

ssh -N -L 13306:db.internal:3306 ubuntu@bastion.example.com

If that works and DevOpsPad does not, compare the username, key and host key settings in the dialog with what OpenSSH used, since DevOpsPad ignores ~/.ssh/config.