Difference between revisions of "SSH/Tunneling"
| Line 37: | Line 37: | ||
==== Explanation ==== |
==== Explanation ==== |
||
This hack |
This hack is using a trick used by load-balancers where a host in an internal [http://tools.ietf.org/html/rfc1918 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 <tt>lo:1</tt> will route the traffic destined for the IP address locally. When traffic hits the local loop interface and the destination port <tt>ssh</tt> 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. |
||
Revision as of 10:17, 23 December 2012
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
Disclaimer: Don't use this on a production machine unless you fully grasp the mechnism.
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.