SSH/Tunneling

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.

Advanced

Tunneling using the actual destination IP

Disclaimers

• 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 a more appropriate in this case. But this is a duct tape solution not meant to last for eternity.

Problem

Case 1

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.

Case 2

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.

Solution

Asuming the target to connect to is 1.2.3.4 on port 56789 and we use 4.3.2.1 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 4.3.2.1 -R 56789:1.2.3.4: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 1.2.3.4 netmask 255.255.255.255 broadcast 1.2.3.4 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 1.2.3.4/32 brd + label lo:1 dev lo

As soon as you bring the interface up you should see traffic going via the tunnel.

Explanation

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.