Tunneling over SSH
This is a collection of the best SSH Hacks I have come up so far. Currently there is only one so there is not much to see really. The one here I have not seen anywhere else so I think it is fairly unique.
Tunneling using the actual destination IP
- Don't use this on a production machine unless you fully grasp the mechanism.
- I'm fully aware that using a tunnel interface would be more appropriate in this case. But this is a duct tape solution not meant to last for eternity.
Create a tunnel on a machine where an application is supposed to connect to a host that has been blocked by a firewall. Condition you can not change configuration and restart the application using the connection.
An application has a hardcoded IP address and the source code is not available or reworking the application, recompiling and testing takes longer than your SLA for downtime allows.
Asuming the target to connect to is 22.214.171.124 on port 56789 and we use 126.96.36.199 as the jump host. Before starting sshd has to accept remote forwards on all interfaces and IP addresses. To do that on the host running actual application the /etc/ssh/sshd_config file requires the AllowTcpForwarding and GatewayPorts to be set to yes
AllowTcpForwarding yes GatewayPorts yes
HUPing the sshd process will enable the new configuration. With ssh this out of the way connection to the host in question.
ssh <JumpHost> -R <LocalPort>:<DestinationIP>:<DestinationPort>
ssh 188.8.131.52 -R 56789:184.108.40.206:56789
On the application host create an interface on the loopback interface (lo under Linux) with this address with the traditional ifconfig it looks like below.
ifconfig lo:1 <DestinationIP> netmask 255.255.255.255 broadcast <DestinationIP> up
ifconfig lo:1 220.127.116.11 netmask 255.255.255.255 broadcast 18.104.22.168 up
With the ip command on Linux this is how it looks like. Note: label lo:1 is optional.
ip addr add <DestiantionIP>/32 brd + label lo:1 dev lo
ip addr add 22.214.171.124/32 brd + label lo:1 dev lo
As soon as you bring the interface up you should see traffic going via the tunnel.
This hack is using a trick used by load-balancers where a host in an internal RFC 1918 network has to respond to requests from global IP address. But in this case the traffic is not inbound like with load-balancers but outbound. Creating the lo:1 will route the traffic destined for the IP address locally. When traffic hits the local loop interface and the destination port ssh will pick it up and send it to the jump host from there it will be sent to the final destination. There is one caveat if there is more traffic to same destination host on other ports this hack will break the rest of the traffic unless more tunnels are created.