The problem: You have SSH access to a locked-down server with limited access to the internet. Perhaps your company policy has decreed this to prevent sensitive data from leaving the server. But you need to get something from the internet onto that server. What to do?
(Obviously, I'm not recommending that you defy company policy and put yourself in trouble. That is entirely on you !)
SSH Reverse proxy/tunneling comes to the rescue!
The SSH server has a "remote forwarding" feature which can create a SOCKS5 proxy on the server. This will proxy requests from the server back out through your ssh client.
This is eminently usable unless your company has disabled this feature in the SSH on the server. And most do not.
This proxy only exists for the lifetime of your SSH session; once you close down the SSH session the proxy is shut down.
To activate the proxy you need to enable it in your SSH client and pick a port number to be used on the server. In the examples below I chose port 1080 (the default for SOCKS5), but you could use any free high-numbered port. If you specify a port which is in use by something else on the server, then your proxy will not start, and attempts to use that port are doomed to fail.
You can enable it on the command line; then it only takes effect for that session:
you@laptop $ ssh -R 1080 yourname@someserver.example.com
OK. Now we have a proxy. How to use it?
The proxy will only be used by commands/apps which have been told to use it - and support the SOCKS proxy protocol. It will not take effect system-wide on the server.
Nowadays most commands/apps that talk to the internet support using a proxy. And by convention, most linux commands use the HTTP_PROXY environment variable and a few others, so you can set these once you arrive at the destination server:
export HTTP_PROXY=socks5://localhost:1080
export HTTPS_PROXY=socks5://localhost:1080
export ALL_PROXY=socks5://localhost:1080
This would make commands like curl
, wget
, git
and most others
work. For commands/apps which do not follow this convention you
will have to configure them manually - exactly how depends on the app.
A Word of Warning
While your SSH session is active with a reverse tunneling socks proxy, then anybody on the remote server can use your proxy. And their traffic will emanate from your ssh client - i.e. probably your laptop.
This can open the door for other users to access your home network or anything else your laptop has got access to - e.g. a VPN connection or services running on your laptop itself.
Remember that closing down your SSH session will also close the proxy. So it is now worth closing sessions you do not use to reduce the risk.
Once you have considered the security implications, you may decide
to make this the default for every ssh
session - which means you do
not need to specify -R
on the ssh
command line all the time.
You can do this by modifying your ~/.ssh/config
accordingly - e.g. with:
Host someserver.example.com
RemoteForward 1080
# Setting environment here may not work, as most SSH servers
# have this feature disabled by default.
# So you may have to set it manually in your session once you arrive...
SetEnv HTTP_PROXY=socks5://localhost:1080 HTTPS_PROXY=socks5://localhost:1080 ALL_PROXY=socks5://localhost:1080
Enjoy