SSH Tunnel Port Forwarding: Essential Guide for 2026

What is SSH Tunneling and What is it Used For?

Dude, if you’ve been in tech for a while, you’ve probably bumped into SSH. But what people don’t always realize is the superpower it hides: tunneling, or SSH Port Forwarding. For me, this is one of those fundamental tools that, even with the avalanche of frameworks and “cloud-native” solutions that pop up every day, continues to be incredibly useful and, frankly, underestimated [exam-labs.com].

Basically, an SSH tunnel is like creating a secure, encrypted bridge between two points on the network [strongdm.com]. Think of it this way: you have a service running on a machine in the cloud, behind a tricky firewall, and you want to access it from your laptop here on Earth. Instead of opening a bunch of ports and exposing the service to the whole wide world, you use SSH to create a secret path, a tunnel itself, that only you know. All traffic passing through this tunnel is encrypted, which means no one along the way can snoop on what you’re doing [medium.com]. That’s the security we’re always looking for, right?

It’s useful for a lot of things, like accessing an internal database that only accepts connections from the private network, or debugging a web application running on a remote server as if it were on your machine [exam-labs.com]. For me, the biggest insight is the ability to bypass firewalls and network restrictions without needing a full VPN, which is often overkill for a specific task.

[!CALLOUT tipo=“opinião sincera”] Many people spend a lot of energy learning complex network tools when SSH already has the solution for 80% of secure connectivity problems. It’s like wanting to buy a rocket to go to the bakery when a bicycle already does the trick. Less is more, especially when “less” is already such a robust technology present on almost every Linux server out there.

In essence, we’re going to learn how to ‘forward’ ports from one machine to another securely. This makes the traffic appear to originate from the SSH server, fooling firewalls and allowing access. It’s a lifesaver for developers, sysadmins, and security architects. And the best part: you don’t need extra software most of the time, as SSH is already installed on most Unix-like systems [digitalocean.com].

How to Create an SSH Tunnel: Local and Remote Port Forwarding

Now that we understand the beauty of SSH tunneling, let’s get our hands dirty. There are three main types of tunneling: local, remote, and dynamic [builtin.com]. Each has its trick and serves a specific situation. I’ll show you the two most commonly used now: local and remote.

Local Port Forwarding (Local Forwarding)

This is the most common type and, in my humble opinion, the most useful for a developer’s daily life. It allows you to access a service on the remote network as if it were running on your local machine [oneuptime.com]. Imagine you have a MySQL database running on a cloud server, on port 3306, and this database only accepts connections from the datacenter’s internal network. You don’t want to expose port 3306 directly to the internet, right? That’s where local forwarding comes in.

You create a tunnel from your laptop (local machine) to the remote server, and point a port on your laptop to the service’s port on the server. OpenSSH can do this using the -L option [digitalocean.com].

The command is something like this:

ssh -L [local_port]:[remote_target_host]:[remote_target_port] [user]@[ssh_server]

Let’s demystify this:

• [local_port]: This is the port on your computer that you will use to access the service. It can be any free port, like 8080, 9000, 3307, etc.
• [remote_target_host]: This is the IP address or domain name of the server where the service is actually running, on the SSH server’s internal network.
• [remote_target_port]: This is the port on which the service is actually listening on remote_target_host.
• [user]@[ssh_server]: This is the user and the IP/domain of the SSH server you will use as a “bridge.” This is the server you have direct SSH access to.

After establishing this connection, if you want to access the MySQL database on the remote server, you simply connect your MySQL client to localhost:[local_port] (for example, localhost:3307). SSH takes care of securely routing the traffic through the tunnel to remote_target_host:remote_target_port. It’s magic, dude!

Remote Port Forwarding (Remote Forwarding)

This one is the lesser-known, but equally powerful, sibling. Remote forwarding does the opposite of local: it exposes a service from your local machine to the remote network [builtin.com]. Imagine a situation where you have a web server running on your machine, on port 8000, and you want a colleague, who only has access to the SSH server in the cloud, to be able to access this service. Or, a more common scenario, for doing “reverse SSH,” useful when your local machine is behind a NAT or firewall that prevents you from receiving outside connections.

The command uses the -R option:

ssh -R [ssh_server_remote_port]:[local_target_host]:[local_target_port] [user]@[ssh_server]

Decoding this:

• [ssh_server_remote_port]: This is the port on the SSH server that will be open and that your colleague will use to access your service.
• [local_target_host]: This is usually localhost (or 127.0.0.1), because the service you want to expose is running on your own machine.
• [local_target_port]: This is the port of the service running on your machine.
• [user]@[ssh_server]: Again, the user and the IP/domain of the SSH server that will be the bridge.

With this tunnel active, your colleague on the SSH server’s network can access your local web service by pointing their browser to localhost:[ssh_server_remote_port] on the SSH server itself. Or, if the SSH server is configured for it, they can access it from another machine on the same network as the SSH server, using the SSH server’s IP and the configured port. It’s a cool way to collaborate or “punch through” firewalls when you don’t have total control of the network.

Step-by-Step: Configuring SSH Tunnels in Practice

Alright, theory is important, but practice is what makes the difference. I’ll give you the exact commands and some tips so you don’t get tangled up when creating your SSH tunnel.

Configuring Local Port Forwarding

Let’s use the MySQL database example I mentioned. Let’s say your SSH server’s IP is 192.168.1.100, your user is devops, and the database is at 10.0.0.5 on port 3306. You want to access it on your local machine via port 3307.

An important tip: if the local port you chose (like 3307) is already in use on your machine, SSH will warn you. Choose another one! And to prevent the SSH connection from dropping if you’re not using it, you can add the -N (does not execute remote commands, only forwards) and -f (puts SSH in the background) options to the command:

ssh -L 3307:10.0.0.5:3306 devops@192.168.1.100 -N -f

This is great for keeping the tunnel running in the background. To kill the process, you would need to find its PID (with ps aux | grep ssh) and use kill [PID].

Configuring Remote Port Forwarding

Now, the inverse scenario. You have a web server running on your local machine on port 8000 (like a python -m http.server 8000). Your SSH server in the cloud is 192.168.1.100, and you want the service to be accessible there on port 8080 of the SSH server.

A catch here: by default, SSH on the remote server only allows the forwarded port (8080 in the example) to be accessed from localhost on the server itself. To allow other machines on the SSH server’s network to access it, you need to add the -g option to the SSH command (and perhaps configure GatewayPorts yes in the /etc/ssh/sshd_config of the SSH server, but that’s a topic for another day and has security implications):

ssh -R 8080:localhost:8000 devops@192.168.1.100 -g

For those who are more visual, a video on how to create an SSH tunnel can really clarify things. It’s a concept that, once it “clicks,” you won’t forget.

Bonus: Dynamic Port Forwarding (Dynamic Forwarding)

This is the “Swiss Army knife” of SSH tunnels. It creates a SOCKS proxy on your local machine that can forward any traffic to the remote network [builtin.com]. It’s like turning your SSH server into a proxy for your machine. This is useful for browsing the internet as if you were on the remote server, accessing various services on the remote network without configuring a tunnel for each one, or even bypassing some network restrictions on your end.

The command uses the -D option:

ssh -D [local_proxy_port] [user]@[ssh_server]

For example:

ssh -D 8080 devops@192.168.1.100

After running this, you configure your browser (or any application) to use a SOCKS proxy on localhost:8080. All traffic passing through this proxy will be routed through your SSH server. For me, it’s the most elegant way to have a “temporary VPN” for specific tasks [superuser.com]. It’s great for testing things from outside the company’s internal network, you know?

Advantages and Use Cases of SSH Tunnels

The advantages of using SSH tunnels are so many that, sometimes, we even forget what a pain it was before we knew about them. The main one, without a doubt, is the security of sensitive data. All traffic passing through the tunnel is encrypted, which protects your credentials, database data, and any other information from eavesdroppers [strongdm.com].

Another advantage is the ability to bypass network restrictions. How many times have you found yourself stuck by a firewall that wouldn’t let you access an internal service? With an SSH tunnel, you use the SSH server as a secure intermediary, and the firewall only sees you connecting to port 22 of the SSH server (the default SSH port), without realizing what’s happening inside the tunnel [exam-labs.com]. It’s the clever Brazilian way of cybersecurity, but in a legitimate manner!

And the use cases? Oh, there are many:

1. Access an internal web interface: Imagine an administration panel for a legacy system that only runs on the internal network. With a local tunnel, you access it from your browser as if you were in the same room as the server.
2. Manage remote databases: As in our MySQL example, you can use your favorite database client to manage remote instances without exposing the database port to the internet.
3. Debug applications: Do you have an API running in a staging environment that only accepts calls from other internal services? You can tunnel that port to your machine and use Postman or Insomnia to test as if you were inside.
4. Create a secure proxy: Using dynamic tunneling (-D), you can configure your browser to route traffic through the SSH server. This is great for accessing geo-restricted websites or adding an extra layer of privacy to your browsing.
5. Access machines behind NAT/Firewall: Remote port forwarding is a blessing for those who have servers or devices on home networks (or IoT) that need to be accessed from outside but don’t have a public IP or are behind complex NATs. You “push” the connection out to your SSH server.
6. Secure file transfer: Although scp and sftp are more common, you can tunnel a port to an insecure FTP or NFS server and add SSH encryption.

[!CALLOUT tipo=“dica de mestre”] For those working with microservices or distributed systems, the ability to access specific services in an isolated and secure manner, without the overhead of a full VPN, is a game-changer. SSH tunneling is not just for security, it’s for productivity too. Less time configuring, more time coding!

In 2026, with the increasing complexity of cloud architectures and the decentralization of development environments, mastering SSH tunneling has become almost an art. It’s a tool that gives you a “superpower” to solve connectivity problems that would otherwise be a huge headache.

SSH Tunnel Security, Alternatives, and Best Practices

Despite all the magic and utility, it’s essential to talk about security. SSH tunneling is inherently secure because it uses the SSH protocol’s encryption. But, as they say, “with great power comes great responsibility.” Inadequate configuration can open serious vulnerabilities [remote.it].

Risks and Vulnerabilities

1. Inadvertent Exposure: If you use remote port forwarding (-R) and allow GatewayPorts on your SSH server, you might accidentally expose a service on your local machine to the internet. I’ve seen many developers do this and then wonder why their college website was being accessed by Chinese bots.
2. Backdoors: Unfortunately, SSH tunneling can be used by malicious actors to create “backdoors” in corporate networks [cisco.com]. An employee with SSH access to a server can create a remote tunnel to expose a service from their machine on the company’s internal network, or vice versa, bypassing security policies.
3. Firewall Evasion: While an advantage, it’s also a risk. If an attacker gains SSH access to a server, they can use tunneling to send non-SSH traffic (like HTTP, FTP) inside the tunnel, bypassing firewalls that only inspect port 22 [cisco.com]. This has been a real risk since 2024 [cisco.com].

Essential Best Practices

• Use SSH Keys, not Passwords: Passwords are easier to guess or intercept. SSH keys are much more secure. And please, use a strong passphrase for your key!
• Restrict SSH Access: Grant SSH access only to those who truly need it. Use user groups, IP limits, and fail2ban.
• Verify the server’s key fingerprint: When you connect to an SSH server for the first time, it shows the key’s “fingerprint.” Always verify that it matches the server’s expected key. If it doesn’t match, it could be a man-in-the-middle attack [cisco.com]. It’s annoying, I know, but it’s crucial!
• Disable PermitRootLogin: Never allow the root user to log in directly via SSH.
• Monitor logs: Keep an eye on SSH logs (/var/log/auth.log on Linux) to identify suspicious activities.
• Use AllowTcpForwarding wisely: In the sshd_config file of the SSH server, you can control whether tunneling is allowed and for which users. Disable it if not necessary.
• High ports: When configuring local or remote tunneling, prefer high, non-standard ports (above 1024) that are not commonly used by other services.

Alternatives to SSH Tunnels

While SSH tunneling is powerful, it’s not the only solution, nor always the best for all cases.

• VPNs (Virtual Private Networks): For accessing entire networks or larger teams, a VPN is more suitable. It creates a secure virtual network that connects your machine to the remote network, as if you were physically there. It’s more comprehensive, but also more complex to configure and maintain.
• SDP (Software-Defined Perimeter) / Zero Trust Network Access (ZTNA): These are more modern and robust solutions that offer granular, identity-based access control, rather than just network-based. Access is “just-in-time” and “least-privilege,” perfect for large corporate environments.
• Cloudflare Tunnel (formerly Argo Tunnel): For securely exposing internal services to the internet without opening firewall ports, this is an excellent alternative. It creates an egress tunnel from your server to Cloudflare.
• Tailscale / Zerotier: These tools create mesh VPNs between your devices, making it easy to access any machine on any network without worrying about firewalls or public IPs.

Ultimately, SSH tunneling is an incredible tool that, if used intelligently and responsibly, can greatly simplify the lives of those working in technology. But, like any powerful tool, it requires respect and a good understanding of its risks. So, go ahead, experiment, but always with security in mind, got it?

Sources

1. https://builtin.com/software-engineering-perspectives/ssh-port-forwarding — A Complete Guide to SSH Port Forwarding ↩
2. https://community.cisco.com/t5/security-knowledge-base/what-is-ssh-tunneling-or-ssh-port-forwarding-what-are-the-risks/ta-p/4998925 — What is SSH Tunneling or Port Forwarding? What are the risks? ↩
3. https://www.digitalocean.com/community/tutorials/ssh-port-forwarding — How To Create SSH Tunnels (Port Forwarding) ↩
4. https://www.exam-labs.com/blog/the-quiet-power-of-ssh-port-forwarding-in-cybersecurity-architecture — The Quiet Power of SSH Port Forwarding in Cybersecurity Architecture ↩
5. https://isabellecda.medium.com/tunelamento-ssh-ssh-tunneling-2fe466e95823 — Tunelamento SSH (SSH Tunneling) ↩
6. https://oneuptime.com/blog/post/2026-03-20-ssh-local-port-forwarding-ipv4/view — SSH Local Port Forwarding: A Comprehensive IPv4 Guide ↩
7. https://www.remote.it/resources/ssh-port-forwarding-risks-and-safer-alternatives — SSH Port Forwarding: Risks and Safer Alternatives ↩
8. https://www.strongdm.com/blog/ssh-tunneling — What is SSH Tunneling? ↩
9. https://superuser.com/questions/361215/how-secure-ssh-dynamic-port-forwarding — How secure SSH dynamic port forwarding? ↩

Read next

• Create WhatsApp AI Chatbot 2026: Essential Free Guide
• Free AI Image Generator 2026: Essential Guide to Create
• Mastering Git Ignore Files 2026: Essential Guide

---

Ready to scale this idea?

Narratron turns topics like this into retention-optimized YouTube scripts in under 2 minutes — magnetic hook, structure, complete SEO, timestamped description and thumbnail prompt ready to ship. 50 free credits, no card required.

Start free with Narratron →