# SSH Proxy — Tips & Tricks > Strategy and pitfalls for SSH Proxy: bind addresses, GatewayPorts, SOCKS DNS leaks, KeepAlive vs. autossh, agent forwarding and tunnel alternatives. Source: https://www.jpkc.com/db/en/tools/ssh-proxy/tips/ Back to overview: [SSH Proxy](https://www.jpkc.com/db/en/tools/ssh-proxy/) · Open the live tool: [www.jpkc.com/tools/ssh-proxy/](https://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](https://www.jpkc.com/db/en/tools/ssh-proxy/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](https://www.jpkc.com/db/en/tools/ip/)** — check bind addresses, networks and private ranges before you put them into a forward or a NO_PROXY list. - **[DNS, SSL, Redirect & URL](https://www.jpkc.com/db/en/tools/dns-ssl-redirect-url/)** — verify that the target host resolves and is reachable before you start debugging the tunnel. - **[Password & key generator](https://www.jpkc.com/db/en/tools/generator/)** — strong passwords for services that sit at the far end of the tunnel. --- The full feature reference is in the [manual](https://www.jpkc.com/db/en/tools/ssh-proxy/manual/), concrete walkthroughs in the [examples](https://www.jpkc.com/db/en/tools/ssh-proxy/examples/). You can try it all in the [tool](https://www.jpkc.com/tools/ssh-proxy/).