SSH software, in both the server and client implementations, has the ability to both build an encryption tunnel and then force and forward traffic in thru the tunnel. As you review this ability on the internet, many are advancing a configuration whereby you connect to your home/external SSH server, and you do so with forwarding rules built into your work PC. Once home, you configure the home/external ssh instance to force outbound traffic to Mywork.org into the tunnel. Once the traffic hits your work PC, it is forwarded back into your workplace. This allows you to do support work w/o VPN clearance and the like. It also has been used in unsafe designs such as connecting the dmz host to the intranet patching server. Now, for your firewall's perspective, this is sole an inside to outside initiated ssh connection.
This is one of the more difficult abilities in ssh to describe and discuss. I hope this summary helps.
jt
Please explain the details: how they are prevented. If you're talking about a firewall, that is the typical block. The issue is this: Once intranet box a connects to DMZ host, the tunnel can be used by the DMZ host to contact box A. if box a has forwarding rules, dmz host can contact all boxes box a can connect to, including all devices is private IP/RFC 1918/3330 devices. So, here is my point, Organizations switch from ftp to ssh for web content posting, for example. If users don't understand forwarding, their machine may be a portal into the intranet, and if you see the connectivity from the firewall, all you have is an intranet to dmz connection. Indeed a few internal customers were approached by external support staff who wanted to use this design, calling it safe because they'd only have the connection terminating at localhost. However, once one has root or Admin on a box, the actual forwarding rules and cron/at job building outbound ssh connection, well, that exercise is left as a challenge to the student...
jt
Being as filled with tripe as you claim, I might have thought I wrote simply enough for you to understand. I guess not? Under agent forwarding, the first hop device doesn't have the private key. You might review the documents on OpenSSH to understand ssh better. In there, you will find big precautions against agent forwarding in an environment that has high potential for compromise. Would you mind posting these enlightening comments of yours on the actual Informit site?
Slashdot Mirror
SSH software, in both the server and client implementations, has the ability to both build an encryption tunnel and then force and forward traffic in thru the tunnel. As you review this ability on the internet, many are advancing a configuration whereby you connect to your home/external SSH server, and you do so with forwarding rules built into your work PC. Once home, you configure the home/external ssh instance to force outbound traffic to Mywork.org into the tunnel. Once the traffic hits your work PC, it is forwarded back into your workplace. This allows you to do support work w/o VPN clearance and the like. It also has been used in unsafe designs such as connecting the dmz host to the intranet patching server. Now, for your firewall's perspective, this is sole an inside to outside initiated ssh connection. This is one of the more difficult abilities in ssh to describe and discuss. I hope this summary helps. jt
Please explain the details: how they are prevented. If you're talking about a firewall, that is the typical block. The issue is this: Once intranet box a connects to DMZ host, the tunnel can be used by the DMZ host to contact box A. if box a has forwarding rules, dmz host can contact all boxes box a can connect to, including all devices is private IP/RFC 1918/3330 devices. So, here is my point, Organizations switch from ftp to ssh for web content posting, for example. If users don't understand forwarding, their machine may be a portal into the intranet, and if you see the connectivity from the firewall, all you have is an intranet to dmz connection. Indeed a few internal customers were approached by external support staff who wanted to use this design, calling it safe because they'd only have the connection terminating at localhost. However, once one has root or Admin on a box, the actual forwarding rules and cron/at job building outbound ssh connection, well, that exercise is left as a challenge to the student... jt
Being as filled with tripe as you claim, I might have thought I wrote simply enough for you to understand. I guess not? Under agent forwarding, the first hop device doesn't have the private key. You might review the documents on OpenSSH to understand ssh better. In there, you will find big precautions against agent forwarding in an environment that has high potential for compromise. Would you mind posting these enlightening comments of yours on the actual Informit site?