Master SSH Reverse Tunneling to Run Ansible Across Isolated Networks

SSH reverse tunneling is a practical way to let two machines in separate networks communicate, and it can be leveraged to run Ansible Playbooks against a fleet of freshly provisioned servers inside a private network.

Preparation

Three machines are involved:

A – Public gateway : IP 121.41.218.68, user root, SSH port 22, sshd enabled.

B – Client machine inside the private network : IP range 10.155.0.0/24, user root, SSH port 22, sshd enabled.

C – Your local workstation (company or home) : IP 127.0.0.1, user root, SSH port 22, sshd not required.

All machines use the root account for simplicity; in production you should use dedicated accounts and keys.

Step 1: Enable SSH server proxy (GatewayPorts)

Edit /etc/ssh/sshd_config on the public gateway (machine A) to turn on GatewayPorts and then restart the SSH service.

sed -i "s/#GatewayPorts no/GatewayPorts yes/g" /etc/ssh/sshd_config
systemctl restart ssh

Enabling this option changes the listening address of the reverse tunnel from the default 127.0.0.1 to 0.0.0.0, allowing remote clients to connect.

Step 2: Create the reverse tunnel from B to A

On a server inside the private network (B) that can reach the public gateway, run:

ssh -lroot -p22 -qngfNTR 8822:localhost:22 121.41.218.68 -o ServerAliveInterval=10

This command establishes a tunnel where port 22 on B is forwarded to port 8822 on A. The ServerAliveInterval=10 option sends a heartbeat every 10 seconds to keep the tunnel alive.

Step 3: Configure a local SSH proxy on C

To make the tunnel transparent for Ansible, add the following entries to ~/.ssh/config on your workstation:

host hosta
    HostName 121.41.218.68
    Port 8822
    User root

host 10.155.0.*
    User root
    Port 22
    ProxyCommand ssh hosta -W %h:%p

With this configuration, any SSH connection to 10.155.0.* will be proxied through the tunnel on A, allowing Ansible to reach the private machines as if they were directly accessible.

Summary

The three steps above constitute the core workflow for SSH-based internal network penetration. For a more robust setup you may also consider:

Generating and distributing SSH key pairs for the three hosts.

Creating a persistent service (e.g., systemd unit) on B to keep the reverse tunnel alive after reboots.

Applying firewall rules on the public gateway A to restrict access to the tunnel port.

Beyond SSH, reverse tunnels can forward other internal services, but the same principles apply. Remember to dismantish tunnels when they are no longer needed to avoid exposing your network to unwanted access.