SSH Proxy — Tips & Tricks

Back to overview: SSH Proxy · Open the live tool: www.jpkc.com/tools/ssh-proxy/

SSH Proxy takes the flag order off your hands — the strategic decisions stay with you. This page collects what matters in practice. The technical groundwork is in the manual.

The tool only builds — you read and verify

SSH Proxy opens no connection and runs nothing. It produces text. Treat every output as a template: read it (the Explanation table helps), adjust hosts and ports, and test in a safe environment before putting anything into production. The disclaimer at the foot of the page says it plainly — misconfigured tunnels can expose internal services.

Bind address: `127.0.0.1` vs. `0.0.0.0`

The most important security decision lives in the bind:

Local Forward binds to 127.0.0.1 by default — the forwarded port is reachable only from your own machine. Leave it that way unless you deliberately need LAN access.
Remote Forward suggests 0.0.0.0. That makes the port public on the server — and only takes effect if the server has GatewayPorts clientspecified. Without that setting, SSH silently binds to the server's 127.0.0.1 no matter what you specify. If you expect external access and get none, the missing server setting is almost always to blame (see the troubleshooting tab, Channel open failed).

SOCKS5: avoid DNS leaks

A common stumble with ssh -D: the tunnel is up, but DNS queries still go through your local resolver — so the far side sees your proxied traffic, but your provider sees which domains you resolve.

When testing with curl, use --socks5-hostname (not --socks5) — then the SOCKS server resolves the name. That's exactly the variant the tool generates in its test commands.
In Firefox, set network.proxy.socks_remote_dns = true.
The troubleshooting tab (DNS resolution not going through SOCKS proxy) offers OS-specific diagnostics.

Keep KeepAlive, use autossh for permanence

The KeepAlive options (ServerAliveInterval=60, ServerAliveCountMax=3) are pre-ticked for a reason: without them SSH often notices a dead tunnel very late. Leave them on.

For tunnels that should always be up, KeepAlive alone isn't enough — it only detects the drop, it doesn't rebuild. That's what Auto-Reconnect is for:

autossh is the more robust route, but needs the program of that name (apt install autossh, brew install autossh; not natively available on Windows — use WSL or the loop there).
The while loop needs no extra software but has no health checks. Note: the tool removes -f here, because the loop must keep the tunnel in the foreground.

Several tunnels? Script instead of hand-juggling

Once you're juggling more than one or two tunnels, the Management Script generator pays off: a script with start/stop/status/restart/list and PID management beats starting them by hand and hunting with ps. Enable Health check and it also verifies the ports are actually listening. To bring everything up at boot, combine it with Autostart Setup (systemd's Restart=always is more robust here than a @reboot cron).

ForwardAgent is a risk — ProxyJump is the answer

In the SSH Config, ForwardAgent yes is deliberately flagged as a security risk: anyone with root on the destination host can use your forwarded agent to wield your keys. If all you really need is a hop through a bastion host, use ProxyJump (-J) instead — it tunnels the connection through without exposing the agent. Likewise, StrictHostKeyChecking no doesn't belong in production; it's marked (insecure) in the tool for good reason.

ControlMaster for many fast connections

When tools like Ansible, rsync or git open many SSH connections in a row to the same host, connection multiplexing saves noticeable time: the first connection becomes the "master", and later ones share it. In the SSH Config you enable this via ControlMaster auto plus ControlPath/ControlPersist. The reference tab explains the management commands (ssh -O check/exit) — and remember to create the socket directory first: mkdir -p ~/.ssh/sockets && chmod 700 ~/.ssh/sockets.

When an SSH tunnel is the wrong tool

SSH tunnels are ideal for quick, ad-hoc access to a single service through an existing SSH server. For other needs there are better means — the reference tab compares them: WireGuard for full network access, ngrok / Cloudflare Tunnel for public-facing endpoints without your own server, Teleport for zero-trust access with an audit trail, Tailscale / ZeroTier for a mesh across many devices. SSH tunnels are also TCP only — for UDP or roaming-friendly interactive sessions, mosh is the better choice.

Combining with other JPKCom tools

IP tool — check bind addresses, networks and private ranges before you put them into a forward or a NO_PROXY list.
DNS, SSL, Redirect & URL — verify that the target host resolves and is reachable before you start debugging the tunnel.
Password & key generator — strong passwords for services that sit at the far end of the tunnel.

The full feature reference is in the manual, concrete walkthroughs in the examples. You can try it all in the tool.