More Trickiness With SSH



More Trickiness With SSH

I saw an article on reddit about SSH trickery. SSH is a very subversive protocol, able to work around many kinds of unwise security policies. Here’s a couple more useful things to know.

1. Better Lurking Through .ssh/config-ery.

Where you’ve got machines lurking behind other machines, inaccesible from the Internet, you can add a clause like this to your .ssh/config file:

Host: lurker
ProxyCommand: ssh /bin/nc %h %p
This causes ‘ssh lurker’ to open an ssh connection to, then use nc (may be called netcat on your system, or you may have to install it yourself) to connect on to lurker (the %h %p interpolates the target hostname and port into the proxy command)

2. Reverse Tunnelling

So you’ve noticed the -L option, right, and you understand that by running:

ssh -L 3128:localhost:3128 gateway.home
you are establishing a tunnel home to your proxy server, and you can now configure your web browser to use localhost:3128 as its proxy server to keep your web traffic private.

But did you know this one? Let’s say you’ve got a machine stuck out in DMZ land and you want to apt-get upgrade the poor thing, pronto. You can’t access the web from this box: security policy. You can’t access your internal proxy: ditto. All you can do is ssh into it. Try this:

ssh -R
From your shell on dmzbox, you can now configure the http proxy as localhost:3128 and start sucking down packages via the reverse tunnel.

3. Tunnel Tunnelling

Every now and then, you need to get control of a box which is sadly hidden away behind a broken hotel NAT network or some kind of Get Smart style VPN setup. You can’t even get an ssh in. It’s either read Unix commands over an international phone line at 3am your time, or train a pigeon to tap out the following:

ssh -L 2222:localhost:22
which, when run on the remote box, opens an ssh tunnel back home, through which you can ssh back into the remote box with ssh -p 2222 localhost

4. ssh tunnels with tap and -w

There’s also a (newish) “-w” option, which turns ssh into a full-on VPN solution rather than just a port-at-a-time port forwarder.

The useful piece of information which I haven’t seen elsewhere is this: you don’t need to allow root ssh logins to use it. Instead, you can use ‘tunctl’ to preconfigure tun or tap devices on each end with the -u option to set their permissions to a non-root user. The easiest place to do this, on Debian/Ubuntu systems, is in /etc/network/interfaces, for example, in host1:/etc/network/interfaces:

auto tap9
iface tap9 inet static
pre-up tunctl -u nick -t $IFACE
post-down tunctl -d $IFACE
and in host2:/etc/network/interfaces:

auto tap9
iface tap9 inet static
pre-up tunctl -u nick -t $IFACE
post-down tunctl -d $IFACE
Now you can ‘ifup’ those interfaces, and then start the VPN by running:

user@host2$  ssh -o Tunnel=Ethernet -w9:9 host1
And the tunnel will be up and running, without needing to create the tunnel as root. You could easily take this one further for an automatic tunnel, setting


© 2009-2011 Nick Moore. Published at:

413 total views, no views today

Bash Socket Programming



You can connect to a socket using Bash by using exec and redirecting to and from the pseudo-path /dev/tcp/<hostname>/<port> or /dev/udp/<hostname>/<port>. For instance, to connect to your localhost SSH port using TCP:

Then, use cat and echo to read or write to the socket. Here is an example read:

Notice that there is no such file as /dev/tcp or /dev/udp. Bash interprets the pseudo-path.

As another example, maybe you want to download a webpage:

Finally, let’s say you wanted to connect to an IRC server. Here is an example:

Sources Advanced Bash-Scripting Guide – Chapter 29 Bash socket programming with /dev/tcp

604 total views, no views today

Poor man’s VPN with SSH | Setting up an SSH tunnel with PuTTY


Article #1 From:
Article #2 From:

Poor man’s VPN with SSH

SSH has port forwarding, dynamic forwarding, and now also IP forwarding. This allows you to create connections out through a firewall, and allow other connections in and out through your SSH-connection, originating at your SSH server. Read on for a few examples of use, and make sure you have the blessing of your security team.

Local forwarding

With local forwarding, you open a local port, and forward it to another host and port from the remote server.

Often used with forwarding to single webservers, proxies, Citrix ICA servers, VNC servers, and Windows Remote Desktop (RDP).

Example with local forwarding

Connect to a server at work, forwarding a connection from port 10080 on my laptop to

I can then open my browser to http://localhost:10080, and do my stuff. Some web applications, though, can be tricky enough to expect a hostname, and for that you need to edit /etc/hosts or equivalent, or you can read on for dynamic forwarding.

Remote forwarding

With remote forwarding, you open a listening port on the remote side, and forward it to another host and port from the local server.

Example with remote forwarding

One useful scenario is to help family members who have PC trouble. For instance: Mom has a problem, calls me, and wonders if I can help, and then clicks an icon on her desktop that does the following thing:

  • Starts Remote Desktop or VNC
  • Connects to my SSH server, with remote forwarding from <vncport1> on the SSH server, to localhost:<vncport1> on her PC.

What I do, is:

  • Connect to my SSH server, with local forwarding from <vncport1> on my laptop, to <vncport1> on the SSH server, which again connects through the remote forwarding to localhost:<vncport1> on mom’s PC.
  • Start a VNC client, and connect to my localhost:5801 on my laptop. This port is now connected through my ssh session, to mom’s ssh session, to her PC.

Dynamic forwarding with SOCKS

OpenSSH’s client has the ability to do dynamic forwarding to act as a local SOCKS server, both for SOCS4 and SOCS5.

Many programs have built-in SOCKS support, so if you enable this, and configure it to use localhost:<socksport> as a SOCKS proxy.

For programs with no built-in SOCKS support, you can use “tsocks”, to intercept networking calls, and work through the SOCKS server.

Example with dynamic forwarding

Then I configure Firefox, for instance, to use the SOCKS server at localhost port 1080, and all my web connections will go through the SSH connection, and appear to be initiated from Much easier than with local forwarding, and works great for remote administration of things from home where you use different hostnames and ports, and perhaps also unroutable IP addresses.

IP forwarding with TUN

Now we’re talking. This is the real thing, we get IP forwarding through a point-to-point interface. This exists only in newer versions of OpenSSH, and is not very well documented yet. Unfortunately, this also includes this document until I have more time to research further.

Example with IP forwarding

Where ‘0’ is the local device tun0, and ‘1’ refers to the remote device tun1. On each side, one needs to set an IP address for host-to-host contact, and add routing and perhaps also NAT for network access.

Beware, as careless use of IP forwarding between sites may have a serious impact on network security, and may make others very angry if used without permission.

Setting up an SSH tunnel with PuTTY

What follow is how to set up as SSH tunnel using PuTTY with the MySQL port (3306) forwarded as an example. After completing this how-to you’ll have port 3306 on your local machine listening and forwarding to your remote server’s localhost on port 3306. Thus effectively you can connect to the remote server’s MySQL database as though it were running on your local box.


This how-to assumes your MySQL installation has enabled listening to a TCP/IP connection. Only listening on is required (and the default as of MySQL 4.1). Although beyond the scope of this how-to, you can verify the server’s listening by using

on the server. Look for


in your

. Also, a trouble-shooting guide.

To achieve the same with PostgreSQL simply use PostgreSQL’s default port, 5432.

to test;

and the manual as pointers for configuration.

Set up the tunnel

Create a session in PuTTY and then select the Tunnels tab in the SSH section. In the Source port text box enter 3306. This is the port PuTTY will listen on on your local machine. It can be any standard Windows-permitted port. In the Destination field immediately below Source port enter This means, from the server, forward the connection to IP port 3306. MySQL by default listens on port 3306 and we’re connecting directly back to the server itself, i.e. Another common scenario is to connect with PuTTY to an outward-facing firewall and then your Destination might be the private IP address of the database server.

Putty Tunnel

Add the tunnel

Click the Add button and the screen should look like this,

Putty Tunnel Added

Save the session

Unfortunately PuTTY does not provide a handy ubiquitous Save button on all tabs so you have to return to the Session tab and click Save,

Putty Session

Open the session

Click Open (or press Enter), login, and enjoy!

Here for reference is an example connection using MySQL Adminstrator going to localhost: note the Server Host address of which will be transparently forwarded.

Mysql Administrator Login

1,438 total views, no views today