Walker News

SSH Port Forwarding – Local VS Remote

I was asked about the difference of SSH Local Port Forwarding and SSH Remote Port Forwarding.

Obviously, well as you can think of, the difference is where does the SSH Tunnel initiated. And, of course, both are secure or encrypted connection!

Visualize SSH Port Forwarding that encrypting insecure TCP connection with SSH tunnel, i.e. via SSH protocol!
Visualize SSH Port Forwarding that encrypting insecure TCP connection with SSH tunnel, i.e. via SSH protocol!

Perhaps, examples of scenario will help one to understand the difference and when to use SSH Local Port Forwarding or SSH Remote Port Forwarding techniques.

SSH LOCAL Port Forwarding VS SSH REMOTE Port Forwarding.

As long as the firewall allows SSH protocol connection, SSH Port Forwarding technique can be implemented:
SSH LOCAL Port Forwarding
The office firewall only allows public networked computers to remote access servers inside the data centre over SSH protocol.

So, your powerful Core 2 Duo home Desktop running Windows Vista Ultimate is not possible to access the Red Hat VNC server over the RFB protocol.

But, the SSH Local Port Forwarding will not only make this impossible to become possible, the secure SSH Tunnel will also encrypt the insecure VNC connection or the RFB protocol!

On the home Desktop that running Windows Vista or its predecessors, one can create SSH Local Port Forwarding with Putty freeware:
  1. Click the Session menu on the Category panel, fill up the remote SSH server IP address or Hostname and select to connect over SSH protocol,
  2. Click the Connection menu, SSH sub-menu, and follow by Tunnels menu,
  3. Specific an unused local TCP port in Source Port text-box (for this example, it’s 777), the Remote VNC server IP Address or Hostname and click the ADD button,
  4. Click the OPEN button to attempt SSH connection to the Red Hat Linux machine with OpenSSH server running,
  5. Once the authentication passed successfully, keep it open and active,
  6. Now, open Windows VNC client and specify the VNC server connection string as localhost:777
  7. Finally, you’re connecting to the Red Hat VNC server in the office data centre via the SSH Tunnel, i.e. SSH protocol that’s allowed by Firewall!

If your home Desktop is running any Linux distribution too, the OpenSSH server/client suites should have installed successfully. If it’s not, at least proceed to install OpenSSH client! With Linux and OpenSSH client, it is quite easy to setup SSH Local Port Forwarding in a minute or less:
  1. At Linux command prompt, execute this simple SSH commands (refers to earlier posts on how to read or understand SSH Port Forwarding command syntax too):
    ssh -L 777:VNC-Server:VNC-Port SSH-ID@SSH-Server

  2. where
    VNC-Server refers to VNC server IP/Hostname,
    VNC-Port refers to VNC server listening port,
    SSH-ID refers to SSH login ID (i.e. Linux account),
    SSH-Server refers to the remote SSH server.
SSH Remote Port Forwarding
The SSH Local Port Forwarding technique is client-oriented, i.e. the SSH Tunnel/Connection is initiated from client side which is going to access the servers services (VNC, POP3, etc).

As its opposite, SSH Remote Port Forwarding is server-oriented. That’s to say, the SSH Tunnel/Connection is started from server side to a target client that will access to the servers services at later time.

When to use it? OK, you’re told by the IT Security team that your remote access from outside will be barred or blocked on weekend and non-working days. Though, if you working at office Desktop on non-working days, the firewall will still allows SSH connections made to access public hosts (due to the careless of IT Security team?)!

So, before you left the office Desktop, you can setup SSH Remote Port Forwarding so as to allow (at least) your home PC remote access back to office servers! Ideally, the home PC should be powered by Linux with OpenSSH server. I’m not sure that WinSSH or Windows version OpenSSH server works on Windows Vista or its predecessors.

At the Red Hat Linux server that running VNC daemon, setup SSH Remote Port Forwarding for your home PC (in this example, the home PC IP Address is

ssh -R 999:localhost:5907 root@

where 5907 is the VNC server listening port number and 999 is the remote listening port on home PC!

Once the authentication passed, you’re connecting back to home PC from the office server, together with a secure SSH Tunnel established via SSH Remote Port Forwarding technique!

Keep the session open and execute a continuous ping command on 3 seconds interval that simulate keep-alive signal to avoid the connection drop off after certain time of idle:

ping -i 3

When you back home later, you can remote access back to Red Hat Linux VNC server inside office data centre by executing this command in home PC:

vncviewer localhost:999

Done! That’s the way to securely remote access office servers with SSH Remote Port Forwarding!
If you’re going to remote access from home PC to the office SSH server rather than VNC server, just make the changes accordingly. For example:

At office SSH server:

ssh -R 999:localhost:22 home-login@

At home PC:

ssh -p 999 office-login@localhost

Isn’t it simple to understand? Hope that you’ll share and enjoy this post!

Custom Search

  1. Walker 27-07-07@22:25

    The Windows VNC Viewer connection string is wrong in this post too. The correct connection string with specific connection port should be


  2. How To Fix Weird Character In Linux Man Page – Walker News 26-09-07@00:19

    […] you’re reading the Linux manual page over the remote session, either with SSH or Telnet protocol, you might notice that there are some weird characters display on some Linux man […]

  3. How To Fix Telnet Rejection Error of Name or Service Not Known: Illegal Seek – Walker News 20-11-08@01:16

    […] all know that telnet is a good remote access protocol in the old days. Now, we prefer SSH protocol because SSH is a secure protocol, i.e. it’s not easy to hack. However, for some reasons, telnet […]

  4. How To Allow Root Login To Telnet Server In Linux? 18-03-09@01:15

    […] at all. So, I guess these people will only abandon telnet client when Microsoft start to bundle Secure Shell (SSH) clients with Windows OS :-( Now back to topic, if you really want to put the Linux host at risk by allowing […]

2018  •  Privacy Policy