SSH Tunneling, Reverse Tunneling, and Proxy

2024-05-13 01:36 WIB - Hendrik Lie

In the previous blogs, we have described the basics of our ssh tunneling infrastructure. The system now serves as our gateway to access devices from work, for example, and also provide a convenient web proxy as a replacement of our VPN. In the following sections, we recapped through some of our use cases:

  1. Use of SSH Proxy as a replacement of VPN
  2. Connect to home computer via ssh
  3. Forward services from home to office
  4. Access resources on local LAN from a shared remote
  5. Check which ports are used for reverse SSH tunnel
  6. My personal setup

Use of SSH Proxy as a replacement of VPN

Our browser is google-chrome, and we want it to connect to our cloud server via a proxy. Therefore we can configure google-chrome to connect to the internet via the configured proxy. The configuration should make google-chrome dependent on the proxy to be present, otherwise it should not be able to connect to the internet.

Read more in this article.

Connect to home computer via ssh

The problem with a normal home network is that it is hidden behind a NAT. Moreover setting up port forwarding is not exactly trivial for end-user. Therefore, since we have a readily accessible remote server, we can leverage it for our purpose.

Read more in this article.

Forward services from home to office

We have some services that we would like to be made available at office for convenience reason. For security purposes we have to use ssh tunnels instead of exposing the port from our home network’s port forwarding. It takes one cloud device we control that we utilized as a bridge between our home computer and office computer.

Read more in this article.

Access resources on local LAN from a shared remote

We have certain resources accessible only from home LAN, and we want to connect to them from anywhere. Given that we have a high availability cloud server, we can use it as a reverse proxy to access specific services we wanted to access. A custom configuration is required, and will be outlined in the article below.

Read more in this article.

Check which ports are used for reverse SSH tunnel

Following this answer, we can check which TCP ports are in state LISTEN and used by sshd using lsof:

$ sudo lsof -iTCP -sTCP:LISTEN | grep sshd

It should output something like the following:

user@remotehost:~$ sudo lsof -iTCP -sTCP:LISTEN|grep sshd
sshd   753  root   3u  IPv4  19286  0t0  TCP *:ssh (LISTEN)
sshd   753  root   4u  IPv6  19298  0t0  TCP *:ssh (LISTEN)
sshd  2039  user   7u  IPv6  24888  0t0  TCP localhost:2222 (LISTEN)
sshd  2039  user   9u  IPv4  24889  0t0  TCP localhost:2222 (LISTEN)
sshd  2039  user  10u  IPv6  24892  0t0  TCP localhost:8385 (LISTEN)
sshd  2039  user  11u  IPv4  24893  0t0  TCP localhost:8385 (LISTEN)
sshd  8141  user   7u  IPv6  60294  0t0  TCP localhost:2223 (LISTEN)
sshd  8141  user   9u  IPv4  60295  0t0  TCP localhost:2223 (LISTEN)

The first two (of user root) are the SSH Daemon, while the rest (of normal user user) are TCP tunnels, each listed twice: one for IPv6 and another for IPv4.

My personal setup

Since the basics are already explained on the previous sections, the next thing we would like to address is how we actually configure our SSH tunneling infrastructure.

homecomputer

First we set up file ~/.ssh/config as follows:

Host cloud-tun
    User                user
    HostName            remotehost
    # connects to ssh at mobile or work
    LocalForward        2223 localhost:2223
    # ssh server
    RemoteForward       2222 localhost:22
    # home syncthing
    RemoteForward       8385 localhost:8384
    # router
    RemoteForward       8090 192.168.100.1:80
    DynamicForward      8257
    ServerAliveInterval 120

Host cloud-tun is configured with four parameters. First we configures SSH tunnels at port 2223 that receives traffic to remote system port 2223. Afterwards we configured a reverse tunnel that forwards traffic to our port 22 from remote system port 2222. Followed with another reverse tunnel that forwards traffic to our port 8384 from remote system port 8385. Then we opened an encrypted SOCKS port 8257 that we can use with our applications.

Then we set up a systemd user service:

# file ~/.config/systemd/user/cloud-tun.service
[Unit]
Description=SSH tunnel to remotehost

[Service]
Type=simple
Restart=always
RestartSec=10
ExecStart=/usr/bin/ssh -F %h/.ssh/config -N cloud-tun

[Install]
WantedBy=default.target

We activate them by enabling and starting our systemd user service:

$ systemctl --user enable cloud-tun
$ systemctl --user start cloud-tun

The systemd user service would run the command specified in ExecStart, and would restart after ten seconds of disconnection. Therefore ensures our service to be available nearly continuously as long as we are logged in.

workcomputer

First we set up file ~/.ssh/config as follows:

# File ~/.ssh/config
Host cloud-tun
    User                user
    HostName            remotehost
    # home syncthing
    LocalForward        8485 localhost:8385
    # connects to home
    LocalForward        8022 localhost:2222
    # ssh server
    RemoteForward       2223 localhost:22
    # router
    RemoteForward       8091 192.168.100.1:80
    DynamicForward      8257
    ServerAliveInterval 120

Host home
    User                pete
    HostName            localhost
    Port                8022
    ServerAliveInterval 120

Host xph
    HostName            xenophone
    Port                8022

Host cloud-tun is configured with four parameters. First we configures SSH tunnels at port 8485 that receives traffic to remote system port 8385. Then another SSH tunnel at port 8022 that connects to remote system port 2222. Afterwards we configured a reverse tunnel that forwards traffic to our port 22 from remote system port 2223. At last we set up an encrypted SOCKS port 8257 that we can use with our applications.

Then we configured a systemd user service:

# file ~/.config/systemd/user/tunnel.service
[Unit]
Description=SSH tunnel to remotehost

[Service]
Type=simple
Restart=always
RestartSec=10
ExecStart=/usr/bin/ssh -F %h/.ssh/config -N cloud-tun

[Install]
WantedBy=default.target

Afterwards we enable and start the service. We activate them by enabling and starting our systemd user service:

$ systemctl --user enable tunnel
$ systemctl --user start tunnel

The systemd user service would run the command specified in ExecStart, and would restart after ten seconds of disconnection. Therefore ensures our service to be available nearly continuously as long as we are logged in.

remotehost

There is no specific configuration needed at remotehost but a working ssh server. Ideally it must only use public key authentication to prevent password brute force hacking.