Editing Tunneling protocol (section)

== {{Anchor|SSH}}Secure Shell tunneling ==
A ''[[Secure Shell]] (SSH) tunnel'' consists of an encrypted tunnel created through an [[Secure Shell|SSH protocol]] connection. Users may set up SSH tunnels to transfer [[unencrypted]] traffic over a network through an [[encrypted]] channel.  It is a software-based approach to network security and the result is transparent encryption.<ref>{{Cite book|last1=Barrett|first1=Daniel J.|url=https://books.google.com/books?id=JFa5aLIII6oC&q=secure+shell+tunneling+protocol&pg=PP11|title=SSH, the Secure Shell: The Definitive Guide|last2=Barrett|first2=Daniel J.|last3=Silverman|first3=Richard E.|last4=Silverman|first4=Richard|date=2001|publisher="O'Reilly Media, Inc."|isbn=978-0-596-00011-0|language=en}}</ref>

For example, Microsoft Windows machines can share files using the [[Server Message Block]] (SMB) protocol, a non-encrypted protocol. If one were to mount a Microsoft Windows file-system remotely through the Internet, someone snooping on the connection could see transferred files. To mount the Windows file-system securely, one can establish a SSH tunnel that routes all SMB traffic to the remote fileserver through an encrypted channel. Even though the SMB protocol itself contains no encryption, the encrypted SSH channel through which it travels offers security.

{{multiple image
 | total_width = 420
 | image1      = Ssh-L-Tunnel.png
 | image2      = SSH Tunnel (remote).png
 | footer      = Local and remote port forwarding with ssh executed on the blue computer.
}}
Once an SSH connection has been established, the tunnel starts with SSH listening to a port on the {{colorbox|lightgreen}}{{nbsp}}remote or local host. Any connections to it are forwarded to the specified {{colorbox|violet}}{{nbsp}}address and port originating from the {{colorbox|orange}}{{nbsp}}opposing (remote or local, as previously) host.

The [[#TCP meltdown problem|TCP meltdown problem]] is often not a problem when using OpenSSH's port forwarding, because many use cases do not entail TCP-over-TCP tunneling; the meltdown is avoided because the OpenSSH client processes the local, client-side TCP connection in order to get to the actual payload that is being sent, and then sends that payload directly through the tunnel's own TCP connection to the server side, where the OpenSSH server similarly "unwraps" the payload in order to "wrap" it up again for routing to its final destination.<ref>{{cite mailing list
| title=Re: Extensions for long fat networks?
| date=2003-06-13
| first=Dan
| last=Kaminsky
| author-link=Dan Kaminsky
| mailing-list=openssh-unix-dev@mindrot.org
| url=https://marc.info/?l=openssh-unix-dev&m=105554033415532
| quote=the TCP forwarding code is pretty speedy as well.  Just to pre-answer a question, ssh decapsulates and re-encapsulates TCP, so you don't have classic TCP-over-TCP issues.}}</ref> Naturally, this wrapping and unwrapping also occurs in the reverse direction of the bidirectional tunnel.

SSH tunnels provide a means to bypass [[firewall (computing)|firewall]]s that prohibit certain Internet services{{snd}} so long as a site allows outgoing connections. For example, an organization may prohibit a user from accessing Internet web pages (port 80) directly without passing through the organization's [[proxy filter]] (which provides the organization with a means of monitoring and controlling what the user sees through the web). But users may not wish to have their web traffic monitored or blocked by the organization's proxy filter. If users can connect to an external SSH [[Server (computing)|server]], they can create an SSH tunnel to forward a given port on their local machine to port 80 on a remote web server. To access the remote web server, users would point their [[web browser|browser]] to the local port at <nowiki>http://localhost/</nowiki>

Some SSH clients support dynamic [[port forwarding]] that allows the user to create a [[SOCKS]] 4/5 proxy. In this case users can configure their applications to use their local SOCKS proxy server. This gives more flexibility than creating an SSH tunnel to a single port as previously described. SOCKS can free the user from the limitations of connecting only to a predefined remote port and server. If an application does not support SOCKS, a proxifier can be used to redirect the application to the local SOCKS proxy server. Some proxifiers, such as Proxycap, support SSH directly, thus avoiding the need for an SSH client.

In recent versions of OpenSSH it is even allowed to create [[TUN/TAP|layer 2 or layer 3 tunnels]] if both ends have enabled such tunneling capabilities. This creates <code>tun</code> (layer 3, default) or <code>tap</code> (layer 2) virtual interfaces on both ends of the connection. This allows normal network management and routing to be used, and when used on routers, the traffic for an entire subnetwork can be tunneled. A pair of <code>tap</code> virtual interfaces function like an Ethernet cable connecting both ends of the connection and can join kernel bridges.