SSH (Secure Shell) Port Forwarding

Need to reach a private database, internal app, or lab host without punching a hole in the firewall? SSH port forwarding is the cleanest way to do it when you already have SSH access to a trusted machine. It creates an encrypted path for traffic so you can create SSH tunnel connections to services that are not publicly exposed.

That matters because many teams work in segmented networks, cloud subnets, or office environments where direct inbound access is blocked. Instead of exposing a service to the internet, you forward traffic through an SSH session and keep the target service hidden. This is common for secure access, firewall traversal, testing, support sessions, and temporary exposure of private services.

There are three core forwarding modes: local forwarding, remote forwarding, and dynamic forwarding. Each solves a different problem, and each is worth understanding before you set up your next tunnel. If you are trying to create SSH tunnel access for development, administration, or troubleshooting, the right mode matters more than most people think.

SSH port forwarding is not just a convenience feature. It is a controlled access pattern that lets you keep services private while still making them reachable when you need them.

What SSH Port Forwarding Is and How It Works

SSH port forwarding is a tunneling method that sends application traffic through an encrypted SSH connection and then delivers it to a destination service. The traffic travels inside the SSH session, which protects it from inspection on untrusted networks. If you need to create SSH tunnel access for a web app, database, or admin console, this is the core idea behind it.

The moving parts are simple. The SSH client listens on a local port or proxy port, the SSH server accepts the tunnel, and the SSH daemon forwards the traffic to the target host and destination port. The target service might be a web server on port 80, PostgreSQL on 5432, or an internal dashboard that only exists on a private subnet.

It helps to separate two ideas: listening on a port and forwarding traffic. Listening means a process is waiting for connections on a port. Forwarding means that incoming traffic is not handled locally; it is relayed somewhere else. With SSH forwarding, the listening port on your machine or the SSH server is just the entry point. The real destination is another host and port that may not be reachable directly.

Simple example

Suppose a remote server hosts an internal web app at 10.10.2.15:80, but that host is not accessible from your laptop. You can create SSH tunnel access so that localhost:8888 on your machine forwards through SSH to that private web app. Then you open your browser to http://localhost:8888 and the remote service appears locally.

This is useful when networks are filtered, segmented, or protected by NAT. It is also useful when you need a temporary route for testing without changing firewall policy. For a concise technical reference on SSH behavior, see the official OpenSSH ssh manual and the related sshd manual.

Types of SSH Port Forwarding

There are three main SSH port forwarding modes: local port forwarding, remote port forwarding, and dynamic port forwarding. The right one depends on where the service lives and who needs to reach it. If you want to create SSH tunnel access for a single private service, local forwarding is usually the simplest answer. If you need someone outside your network to reach a service on your machine, remote forwarding is the better fit. If you need proxy-style routing to multiple destinations, dynamic forwarding is the flexible option.

Each mode uses the same SSH foundation: authentication, encryption, and session control. The difference is where the listening port sits and where traffic goes after it enters the tunnel. That distinction drives the use case.

Quick comparison

Local forwarding	Best when you want to reach a private remote service from your own computer.
Remote forwarding	Best when you want a service on your machine to be reachable through the SSH server.
Dynamic forwarding	Best when you want a SOCKS proxy that can route to multiple destinations without defining each one in advance.

OpenSSH documents these modes directly in the ssh(1) manual. If your environment is managed through Microsoft infrastructure, the SSH client guidance in Microsoft Learn is also useful for Windows hosts.

Local Port Forwarding

Local port forwarding sends traffic from a port on your computer to a port on a remote host through SSH. This is the most common way to access a private service behind a firewall. If you want to create SSH tunnel access to an internal web app or database, local forwarding is usually the first command people learn.

A practical example is forwarding localhost:8888 to remote-server:80. Your browser connects to the local port, SSH carries the traffic to the remote server, and the web app responds as if it were local. The same pattern works for PostgreSQL, MySQL, internal admin panels, and test APIs.

Why local forwarding is so common

• Development — test a staging app without opening it to the public internet.
• Troubleshooting — reach a service only available on a private subnet.
• Administration — connect to dashboards and databases through a controlled path.
• Security — avoid exposing ports directly on the target host.

A typical command pattern looks like this:

ssh -L 8888:10.10.2.15:80 user@jump-host

In this example, your local port 8888 forwards to 10.10.2.15:80 through the SSH server at jump-host. Once connected, open http://localhost:8888 in a browser.

Common mistakes to avoid

• Port conflict — the chosen local port is already in use.
• Wrong destination — the remote host or port is typed incorrectly.
• Service not running — the target application is down or listening on a different port.
• Access denied — the SSH account cannot reach the private destination network.

If you work with code tools that need private services, local forwarding is also common for code server SSH workflows, especially when a browser-based IDE or internal tool listens behind a restricted host.

For cloud environments, the same idea often appears in documentation as gcloud port forwarding, where a cloud-hosted VM or bastion is used to reach a private instance. The pattern is still SSH tunneling at its core.

Remote Port Forwarding

Remote port forwarding does the opposite of local forwarding. It exposes a port on the SSH server side and sends incoming traffic back through the tunnel to a service running on your machine or another reachable local system. If you need to create SSH tunnel access so someone can reach a local demo app from a remote server, this is the mode you want.

This is often used for temporary demos, support sessions, and services behind NAT. For example, you might run a local web app on localhost:8888 and forward a remote port on the SSH server so another user can open the server’s address and reach your app. The external user never connects to your machine directly.

Why remote forwarding matters

Remote forwarding is useful when your device is behind a home router, corporate NAT, or firewall and cannot accept inbound connections. You open one outbound SSH connection to a trusted server, and that server becomes the entry point. In practice, this gives you a controlled way to share a service without reconfiguring your network.

A common command pattern looks like this:

ssh -R 9090:localhost:8888 user@remote-server

That means port 9090 on the remote server forwards back to your local port 8888. Anyone who can reach the remote server and port 9090 can reach your local app, subject to SSH server policy and bind settings.

Security considerations

• Binding scope matters — a remote port may be reachable by more users than you expect.
• Server policy may block remote forwarding entirely.
• Shared hosts may expose the forwarded port to other accounts if configured broadly.
• Temporary use is safer than leaving remote forwards running longer than necessary.

When you search for ssh -r remote port forwarding, you are usually looking for this exact mode. The ssh -r remote port forwarding explanation is simple: the remote server listens first, and your local service receives the traffic through the SSH session.

OpenSSH details the behavior in the ssh manual. For server-side controls, review sshd_config settings such as forwarding permissions and gateway-related options.

Dynamic Port Forwarding

Dynamic port forwarding turns SSH into a SOCKS proxy. Instead of forwarding one fixed destination, it can route traffic to multiple destinations through a single local listener. If you need to create SSH tunnel access for browsing, testing, or reaching several internal services, dynamic forwarding is often the most flexible option.

This mode is different from local and remote forwarding because you are not predefining one target host and port. Your browser or application sends traffic to a local SOCKS proxy, and SSH decides where to send it based on the destination request. That makes it ideal for scenarios where you want one tunnel and many possible endpoints.

Typical uses for dynamic forwarding

• Private browsing through a trusted remote server.
• Access to multiple internal sites without creating separate tunnels.
• Ad hoc troubleshooting across several web apps during an incident.
• Lab work where the target systems change frequently.

The typical command pattern is:

ssh -D 1080 user@jump-host

That starts a SOCKS proxy on local port 1080. Your browser, curl, or other SOCKS-aware application can then use localhost:1080 as its proxy setting. Once configured, traffic to different destinations flows through the same SSH session.

In the command-line help, you may see references to man ssh -d dynamic port forwarding. That wording reflects the common SSH option used to create a dynamic SOCKS listener. The behavior is the same: one local proxy, many possible destinations.

When dynamic forwarding wins

Use dynamic forwarding when you do not want to define a separate tunnel for every site, host, or service. It is especially useful for privacy-oriented browsing on untrusted networks or when you need to pivot between several internal resources during a session. That said, not every application speaks SOCKS cleanly, so test the client before you depend on it.

For browser configuration, set the SOCKS proxy in the application’s network settings. For command-line testing, tools like curl can often use a SOCKS proxy directly. The official OpenSSH manual remains the best reference for exact option behavior.

Common Use Cases and Real-World Examples

Developers, sysadmins, and support engineers use SSH port forwarding for the same reason: they need safe access to services that should not be public. If you need to create SSH tunnel access during a sprint, an outage, or a lab exercise, the use cases are usually straightforward.

Developers often forward staging databases, test APIs, or internal preview apps. For example, a team might connect a local SQL client to a PostgreSQL instance running in a private subnet. That avoids changing security groups or opening the database to broader network access.

Examples by role

• Developers — view an internal web app in a browser through localhost.
• Database admins — connect securely to MySQL or PostgreSQL on a private host.
• Sysadmins — manage dashboards, hypervisors, and appliances without exposing management ports.
• Support teams — reach a customer-facing service temporarily during a troubleshooting window.

SSH forwarding also helps when you are working across VPN-less environments, home labs, or isolated cloud instances. Instead of standing up new network paths, you use one trusted SSH endpoint as the bridge. In cloud workflows, this is often paired with bastion hosts or jump servers. In lab networks, it is often the fastest way to get access without rearchitecting the topology.

Common services forwarded through SSH include:

• HTTP and HTTPS
• SSH to reach another internal host
• PostgreSQL
• MySQL
• Internal dashboards and admin portals

For cloud-specific examples, Microsoft documents SSH access patterns in Azure VM guidance, while AWS explains secure connectivity patterns in its official documentation. Those vendor guides are useful when forwarding is part of a larger access design.

Setting Up SSH Port Forwarding

Before you create SSH tunnel access, make sure you have the basics in place: an SSH client, network reachability to the SSH server, and permission to log in. You also need to know the destination host and destination port for the service you want to reach. Without those details, tunnel setup turns into guesswork.

The general syntax is simple, but the direction matters. Local forwarding uses -L, remote forwarding uses -R, and dynamic forwarding uses -D. If an environment blocks forwarding, the SSH server configuration may need to allow it first.

Before you connect

1. Identify the target service and confirm the port number.
2. Choose an unused local port for the listener.
3. Confirm SSH access to the jump host or server.
4. Check server policy for forwarding permissions.
5. Test the destination directly if possible from the SSH server side.

Server-side configuration is often controlled in sshd_config. Settings such as AllowTcpForwarding, GatewayPorts, and related restrictions determine what kind of forwarding is permitted. OpenSSH documents these options in sshd_config(5).

After setup, test the tunnel immediately. Open the browser, connect with the database client, or hit the local proxy endpoint. If it fails, check the SSH session output first. Most problems are visible there.

Step-by-Step Local Forwarding Setup

Local forwarding starts with a command that tells SSH which local port to listen on and which remote destination to reach. If you are trying to create SSH tunnel access to a private app, this is the place to begin.

A standard pattern looks like this:

ssh -L 8888:10.10.2.15:80 user@jump-host

Here is how to read it:

• 8888 is the local listener on your computer.
• 10.10.2.15 is the target host reachable from the SSH server.
• 80 is the destination service port.
• user@jump-host is the SSH account and server you use to open the tunnel.

How to verify it

1. Open the SSH session and keep it running.
2. Launch a browser or client against localhost:8888.
3. Confirm the page or service response comes from the remote target.
4. If needed, test with curl http://localhost:8888.

For database access, the same logic applies. A DBA might forward localhost:15432 to a PostgreSQL server on 5432, then point the SQL client at 127.0.0.1:15432. That keeps the database off the public network while still making it usable from the workstation.

When the SSH session ends, the tunnel closes. That is expected. If you need a longer-running tunnel, run it inside a terminal multiplexer or a managed process, but only if your operational policy allows it.

Step-by-Step Remote Forwarding Setup

Remote forwarding flips the direction. You ask the SSH server to listen on a port and send the traffic back to your local service. If you need to create SSH tunnel access for a demo or support session, this is the technique to use.

The command pattern looks like this:

ssh -R 9090:localhost:8888 user@remote-server

This means remote server port 9090 forwards to your local port 8888. Someone connecting to the remote server and port 9090 reaches your local app through the SSH session.

Choosing the right port

Select a port that is allowed by policy and unlikely to collide with an existing service. On shared servers, port conflicts are common. On restricted hosts, low ports may require elevated privileges or special binding rights. If the SSH daemon rejects the bind, check permissions and server-side forwarding settings first.

Testing remote access

1. Start the remote forward and keep the SSH session open.
2. From a second machine, connect to remote-server:9090.
3. Confirm the response comes from your local application.
4. Inspect SSH logs or session output if the connection fails.

Remote forwarding is useful when a customer, coworker, or tester needs temporary access to a service on your laptop or workstation. It is also useful in NAT-heavy environments where inbound connections are not possible. If the server is configured with permissive bind behavior, review whether that port should be limited to localhost or a specific interface.

The GatewayPorts SSH setting is the key server-side control people often miss. It affects whether the remote forward is bound only to localhost or made reachable on broader interfaces. That is a policy decision, not a convenience setting, so handle it carefully.

Step-by-Step Dynamic Forwarding Setup

Dynamic forwarding creates a SOCKS proxy on a local port and lets applications choose destinations on the fly. If you need to create SSH tunnel access to multiple internal sites, this is usually the most practical approach.

Start the proxy with a command like this:

ssh -D 1080 user@jump-host

That opens a local SOCKS listener on port 1080. Then configure your browser or application to use SOCKS5 proxy localhost:1080. The application sends destination requests to SSH, and SSH relays them through the tunnel.

Where dynamic forwarding fits best

• Browser access to several internal apps.
• Private network testing without defining multiple tunnels.
• Security reviews where traffic must flow through one controlled path.
• Temporary proxying during troubleshooting or lab work.

This is different from forwarding a single fixed destination. Local forwarding says, “take this port and send it there.” Dynamic forwarding says, “take this port and proxy to whichever destination the application asks for.” That distinction is what makes it so flexible.

For browsers, the proxy settings are usually under network or advanced connection options. For command-line tools, SOCKS support varies, so check the client documentation before you rely on it. If a tool cannot use SOCKS directly, local forwarding may be the simpler answer.

Security Considerations and Best Practices

SSH port forwarding encrypts the tunnel, but it does not automatically make the target service secure. If the application itself is weak, exposed through a tunnel, or poorly controlled, you still have a risk problem. The safest way to create SSH tunnel access is to combine forwarding with strong SSH authentication, limited privileges, and tight destination control.

Use key-based authentication wherever possible. Restrict who can log in, and avoid shared accounts for forwarding. If your SSH server supports it, limit forwarding to specific users or hosts. On the target side, only forward the ports you truly need. A tunnel to a database should not also become a path to unrelated internal systems.

Best practices that matter

• Use SSH keys instead of passwords where possible.
• Limit forwarding permissions in sshd_config.
• Bind narrowly when exposing remote ports.
• Log and review usage for unexpected tunnels.
• Close tunnels promptly when the task is complete.

In regulated or sensitive environments, review the tunnel design against internal security policy and network segmentation requirements. NIST guidance on secure remote access and system boundary protection is a useful reference point. For broader context, see NIST CSRC and related SP 800 guidance. If your team manages public-facing services, the CIS Benchmarks are also worth checking for host hardening guidance.

Firewall, NAT, and Network Access Scenarios

SSH forwarding is especially useful when direct connections are blocked by firewalls, segmented subnets, or NAT. If you need to create SSH tunnel access without requesting a new firewall rule, SSH can serve as the controlled middle path. This is common in office networks, cloud VPCs, and home labs.

Behind NAT, internal hosts often cannot be reached from the outside world at all. Remote port forwarding works well here because the connection starts outbound from the internal system. That means the NAT device allows it, and the forwarded port becomes reachable through the SSH server instead of directly.

When SSH forwarding makes sense

• Cloud instances that sit in private subnets.
• Office systems shielded by restrictive firewall policy.
• Home labs where you want temporary access without router changes.
• Segmented environments where direct east-west or north-south traffic is blocked.

That said, SSH forwarding is not always the best answer. If multiple users need steady access to many internal services, a VPN or dedicated reverse proxy may be a better fit. SSH tunnels are excellent for targeted, user-driven access. They are less ideal as a broad replacement for a managed access layer.

For cloud operators, vendor documentation is useful when choosing the right pattern. AWS and Microsoft both document secure access approaches for private compute resources, and those references help when SSH tunneling is part of a larger access model. The best solution is the one that fits the policy, not just the one that works technically.

Troubleshooting SSH Port Forwarding

Most SSH forwarding failures come down to a small set of problems: port conflicts, authentication issues, wrong hostnames, or a destination service that is not running. If you cannot create SSH tunnel access, start with the basics before assuming the network is broken.

Common checks

1. Confirm the SSH login works without forwarding first.
2. Check the local port to see whether something else is using it.
3. Verify the target host and port are correct.
4. Test destination reachability from the SSH server side.
5. Review sshd_config for forwarding restrictions.

If a local port is already occupied, choose another one. If the SSH session connects but the forwarded service fails, the problem may be upstream: the remote host may be down, the app may be bound to the wrong interface, or network policy may block the path from the SSH server to the destination.

For quick validation, use simple tools. Try curl for HTTP, a browser for web apps, or database clients for SQL services. On the host itself, process checks such as ss -ltnp or netstat can confirm whether a service is listening on the expected port. Application logs are often the fastest way to find a bind or auth error.

When remote forwarding fails, the server may be enforcing a bind policy or disallowing port forwarding entirely. When dynamic forwarding fails, the issue may be the client not actually using the SOCKS proxy settings. Always isolate the problem one layer at a time.

Tools, Commands, and Workflow Tips

Most SSH clients support port forwarding directly from the command line, which makes them quick to use in ad hoc situations. If you often need to create SSH tunnel connections, saving the details in an SSH config file is usually the best workflow improvement you can make.

An ssh config entry can store host aliases, user names, identity files, and forwarding rules. That saves time and reduces mistakes. Instead of typing a long command every time, you connect to a short alias and let the config handle the tunnel.

Practical workflow tips

• Use host aliases to simplify repeated tunnel commands.
• Document port mappings so teammates know what each tunnel does.
• Use terminal multiplexers for long-running sessions when allowed.
• Automate carefully with scripts only when the use case is stable.
• Check logs first when something stops working.

SSH forwarding fits naturally into the same secure access stack used by SFTP and SCP. Those tools rely on the same encrypted SSH foundation. That consistency is one reason SSH remains so widely used for administrative access and secure file movement. For official command behavior, keep the OpenSSH manual close at hand.

For teams, workflow discipline matters. Record the purpose of the tunnel, the owner, the destination service, and the expiration time if it is temporary. That keeps tunnels from becoming invisible infrastructure.

Conclusion

SSH port forwarding is a practical way to secure traffic and reach restricted services without exposing them directly. If you need to create SSH tunnel access for development, administration, troubleshooting, or private service exposure, it gives you a controlled encrypted path that works in a wide range of network conditions.

Local forwarding is best for reaching remote private services from your own machine. Remote forwarding is best when someone needs to reach a service running on your side. Dynamic forwarding is best when you want SOCKS-based proxying to multiple destinations through one SSH session.

The key is to use the right mode for the job and keep security tight. Limit who can connect, forward only what you need, and review server settings before relying on a tunnel in production or shared environments. For more detail, consult the official OpenSSH documentation, Microsoft Learn, NIST, and the CIS Benchmarks.

Use SSH forwarding with intent, document what you build, and close the tunnel when the task is done. That is how IT teams keep access simple without making the network messy.