Forwarding Connections with OpenSSH

Remote Proxy | Roaming SubEthaEdit | Reverse SSH Tunnel

OpenSSH can forward TCP connections over a Secure Shell (SSH) connection. Read on for example uses.

Remote Proxy

Web requests can be routed over SSH, to allow access to protected resources, or to hide web requests made on an open wireless network. This requires a cache such as squid setup on a bastion system. The roaming clients establish a tunnel via a LocalForward setting in an appropriate ~/.ssh/config entry:

Host bastion bastion.example.org
Hostname bastion.example.org
LocalForward 1234 127.0.0.1:3128

And then configure web browsers to use 127.0.0.1:1234 as the HTTP and other proxies. ssh_config(5) contains more information on the various OpenSSH configuration options.

Roaming SubEthaEdit

SubEthaEdit allows collaborative real-time editing of documents. If run on a laptop, editing over the Internet may not be possible, due to firewalls. However, with a static server available to connect to, a SSH connection can be used to create a tunnel to SubEthaEdit. Downsides of this approach: the server must open up a port for remote access, and either forward the port to 127.0.0.1:6942, or enable GatewayPorts in the server’s sshd_config file.

Once the server allows 6942 in, on the laptop, a ~/.ssh/config entry should be used to create this forward automatically:

Host server.example.org
RemoteForward 6942 127.0.0.1:6942

Connect from the laptop to the server:

$ ssh server.example.org

Then, have other systems connect to see://server.example.org using SubEthaEdit.

Reverse SSH Tunnel

Firewalls may deny incoming SSH connections, but allow outgoing SSH. Using forwarding, an incoming path may be setup by tunneling access to the internal sshd server over a persistant outbound connection. Warning! This use of SSH may impose a security risk to the site in question, or be a security policy violation!

  1. Connect from the internal system to the external host. Use the -R option to open port 2222 on the external host back to port 22 on the internal system.
  2. internal$ ssh -R 2222:127.0.0.1:22 external.example.org

  3. On the external host, connect back in from the external host.
  4. external$ ssh -p 2222 127.0.0.1

    Setting the NoHostAuthenticationForLocalhost yes option might be required to avoid key conflicts, if multiple connections are done using the localhost address. For more information, see ssh_config(5).