Difference between revisions of "SSH/Tunneling"
(7 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
{{DISPLAYTITLE: Tunneling over SSH}} |
{{DISPLAYTITLE: Tunneling over SSH}} |
||
[[Category: SSH]] [[Category: Hacks]] |
[[Category: SSH]] [[Category: Hacks]] |
||
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 == |
== Advanced == |
||
=== Tunneling using the actual destination IP === |
=== 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 more appropriate in this case. But this is a duct tape solution not meant to last for eternity.''' |
|||
==== Problem ==== |
==== 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. |
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 ==== |
==== Solution ==== |
||
Asuming the target to connect to is <span class="highlight">1.2.3.4</span> on port <span class="highlight">56789</span> and we use <span class="highlight">4.3.2.1</span> as the jump host. |
Asuming the target to connect to is <span class="highlight">1.2.3.4</span> on port <span class="highlight">56789</span> and we use <span class="highlight">4.3.2.1</span> as the jump host. |
||
Line 19: | Line 26: | ||
ssh <span class="highlight">4.3.2.1</span> -R <span class="highlight">56789:1.2.3.4:56789</span> |
ssh <span class="highlight">4.3.2.1</span> -R <span class="highlight">56789:1.2.3.4:56789</span> |
||
On the application host create an interface on the |
On the application host create an interface on the loopback interface (<tt>lo</tt> under Linux) with this address with the traditional <tt>ifconfig</tt> it looks like below. |
||
ifconfig lo:1 <span class="input"><DestinationIP></span> netmask 255.255.255.255 broadcast <span class="input"><DestinationIP></span> up |
ifconfig lo:1 <span class="input"><DestinationIP></span> netmask 255.255.255.255 broadcast <span class="input"><DestinationIP></span> up |
||
ifconfig lo:1 <span class="highlight">1.2.3.4</span> netmask 255.255.255.255 broadcast <span class="highlight">1.2.3.4</span> up |
ifconfig lo:1 <span class="highlight">1.2.3.4</span> netmask 255.255.255.255 broadcast <span class="highlight">1.2.3.4</span> up |
||
With the <tt>ip</tt> command on |
With the <tt>ip</tt> command on Linux this is how it looks like. |
||
'''Note:''' <tt>label lo:1</tt> is optional. |
'''Note:''' <tt>label lo:1</tt> is optional. |
||
ip addr add <span class="input"><DestiantionIP></span>/32 brd + label lo:1 dev lo |
ip addr add <span class="input"><DestiantionIP></span>/32 brd + label lo:1 dev lo |
||
Line 30: | Line 37: | ||
As soon as you bring the interface up you should see traffic going via the tunnel. |
As soon as you bring the interface up you should see traffic going via the tunnel. |
||
==== 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. |
Latest revision as of 16:50, 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
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 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.