I recently discovered the power of SSH tunneling: a Swiss Army knife for your remote services control when the only access available for your server is SSH.
If your remote server only provides SSH access and you need to access (debug, test, check..) the available services on that machine SSH Tunneling is your rescue. Keeping things simple: SSH let you open a listening socket on your machine, while redirecting all its traffic to a specific port on your SSH-accessed host.
In the following example I will describe this scenario: on my remote server (IP: x.x.x.x) a Solr instance has been configured as a search service, it has been locked to accept only local connections coming from 127.0.0.1, and I need to check its configuration by the Solr admin panel (usually reachable on port 8983). The remote server is only accessible by SSH (port 20) and HTTPS (port 443).
With SSH Tunneling I was able to access the Solr admin panel from my browser: all the data is piped through the web and to the server by SSH.
The command I used is quite simple:
ssh -L localhost:8080:127.0.0.1:8983 firstname.lastname@example.org -N -C
- 8080 is the local port where the tunneling starts from (on machine)
- 127.0.0.1:8983 is the destination IP:port for my request; in other words where the tunnel points to ( as seen as if the connection starts once logged into the remote server)
- email@example.com the remote SSH credentials
- -N don’t send any command through SSH, simply wait on the shell
- -C enable SSH protocol compression (we care about speed, don’t we?)
Once the connection has been established and the SSH tunnel build, we can visit “http://localhost:8080” to actually access the remote Solr admin interface.
For a more detailed description of SSH Tunneling use cases, please check SSH manual