How It Works

This tool converts the tunnel you want into a single SSH command. You choose the tunnel type (local, remote, or dynamic), enter the SSH server details, define which ports to bind, and optionally add hardening and convenience flags like identity keys, jump hosts, keepalives, compression, and background mode. The generator then outputs a command that you can paste into your terminal.

Simple workflow

• 1) Pick a tunnel type: local (-L), remote (-R), or dynamic (-D).
• 2) Define endpoints: local bind address/port, remote host/port, and the SSH server you connect to.
• 3) Add optional flags: key file (-i), jump host (-J), compression (-C), keepalive settings, and more.
• 4) Copy and run: paste the command into a terminal and validate the tunnel with a quick test (curl, nc, browser proxy).

Key Features

Local Port Forwarding (-L) builder

Create commands that expose a remote service on your machine. This is ideal when a database, admin panel, or internal API is only reachable from an SSH host, but you want to access it locally as localhost:PORT.

Remote Port Forwarding (-R) builder

Generate commands that publish a local service to the remote side. This is handy when you’re developing locally but need a remote environment to reach your laptop, CI runner, or a private webhook endpoint.

Dynamic SOCKS proxy (-D) builder

Build a dynamic tunnel that acts as a SOCKS proxy. Point your browser or system proxy settings to the local SOCKS port to route traffic through the SSH server (useful for secure browsing on public Wi‑Fi or testing geofenced routing in a controlled way).

Security-focused options

Include safer defaults like disabling remote commands (use -N), selecting an identity key, forcing an SSH port, and adding keepalive intervals so tunnels don’t silently die. You can also bind to 127.0.0.1 to keep the tunnel local-only.

Copy and download output

One click to copy your generated command, plus a download option for saving a command snippet in a file for later reuse or documentation.

Use Cases

• Access a private database: Forward a remote PostgreSQL/MySQL port to your laptop, then connect with your GUI client to localhost.
• Reach internal dashboards: Tunnel an internal web UI safely without opening firewall rules.
• Expose a local dev server: Use remote forwarding so teammates or a remote integration test can hit your local app.
• Secure browsing on public networks: Create a SOCKS proxy and route your browser traffic through a trusted SSH server.
• Debug microservice networking: Temporarily forward ports to reproduce issues without redeploying services.
• Webhook testing: Publish a local webhook listener to a remote host that your SaaS provider can reach.
• Incident response: Establish a controlled, authenticated path to an isolated host during investigation.

These scenarios share a common need: connect to something that is reachable from an SSH host but not from your current network. SSH tunneling creates that bridge with encryption, authentication, and a clear audit trail on the SSH server.

Optimization Tips

Prefer local-only binds unless you truly need exposure

When creating a local forward, bind to 127.0.0.1 (or localhost) so the forwarded port isn’t reachable from other devices on your network. Only bind to 0.0.0.0 if you understand the risk and have a reason to share the tunnel.

Keep tunnels stable with keepalives

Some networks aggressively time out idle connections. Consider adding ServerAliveInterval and ServerAliveCountMax options so the client detects broken links and reconnects faster when needed.

Use jump hosts and key authentication for safer operations

If the SSH server is only reachable through a bastion, add a jump host (-J). Prefer key-based authentication, store keys securely, and use an SSH agent where appropriate. When you’re done troubleshooting, close the tunnel and remove any temporary forwarding rules.

FAQ

Deep Dive: Understanding SSH Tunnels

An SSH tunnel is essentially an encrypted TCP connection that carries other TCP connections inside it. When you run a forward, SSH listens on one side (local or remote) and then ships the traffic through the encrypted session to the other side, where it is connected to the target host and port. From an application’s perspective, it looks like it is connecting to a normal socket, but the packets travel securely through the SSH link.

This approach is popular because it avoids opening additional firewall holes. If you can SSH into a machine, you can often reach services behind it without exposing those services to the public internet. It’s also an excellent diagnostic tool: you can confirm whether a problem is “network reachability” versus “application configuration” by forwarding a port and testing directly.

Local forwarding is the most common: you bind a port on your laptop and forward to a private destination such as 10.0.0.5:5432. Remote forwarding flips the direction: the server opens a port and forwards traffic back to you. Dynamic forwarding goes further by creating a SOCKS proxy that can decide destinations at request time, which is why browsers and proxy-aware tools work well with it.

While tunneling is convenient, it should be treated as temporary infrastructure. Use least-privilege accounts, restrict binds to localhost where possible, and close tunnels when you’re done. On shared servers, review SSHD settings like AllowTcpForwarding and GatewayPorts to ensure forwarding behavior matches your organization’s policy.

Practical Examples You Can Generate

Forward a remote PostgreSQL database to your laptop

Developers often need to inspect data in a staging database that is not internet-accessible. With local forwarding you can map remote port 5432 to a safe local port like 15432, then connect your database client to localhost:15432. This keeps the database private while giving you full client compatibility.

Create a SOCKS proxy for secure browsing

Dynamic forwarding is a clean way to route traffic through a trusted host. After creating a SOCKS tunnel on port 1080, set your browser to use SOCKS5 on 127.0.0.1:1080. DNS handling depends on the browser; many can proxy DNS requests too, which prevents local network observers from seeing lookups.

Expose a local webhook listener to a remote server

If an external service can only call back to a public server you control, you can remote-forward a port from that server to your laptop. The public server receives the webhook and SSH forwards it through the tunnel into your local listener. This is useful for verifying payloads and signature validation without deploying a temporary endpoint.

Use a jump host in segmented networks

Many production environments require connecting through a bastion. The jump host option adds -J so the SSH client automatically performs the multi-hop route. You still get a single command that you can paste and reuse, without manually maintaining multiple SSH config blocks.

Harden a tunnel for long-running sessions

For tunnels that must run for hours, stability matters. Keepalives help detect broken sessions, and background mode (-f with -N) keeps your terminal free. You can also add ExitOnForwardFailure=yes so the command fails fast if the requested bind cannot be created.

More Optimization Tips

Validate the tunnel with small, repeatable checks

After launching a tunnel, confirm it is listening locally with a command like ss -lnt or netstat -an. Then test the forwarded destination using a minimal client: curl for HTTP, nc for raw TCP, or your database CLI for DB ports. This isolates issues quickly and prevents chasing unrelated application bugs.

Prefer explicit options over implicit defaults

SSH defaults vary across environments. If you depend on a non-standard SSH port, specify it. If you must use a particular identity key, include -i. If you rely on keepalive behavior, include it in the generated command. Being explicit makes commands portable and easier to audit in runbooks.

Document temporary access and remove it afterward

In teams, tunnels often become “tribal knowledge.” Save the generated command into a secure notes system or an internal wiki with context: what service it targets, who is allowed to use it, and when it should be used. When the incident or task is complete, close the tunnel and clean up any temporary firewall or SSHD changes you made to support it.