I do a lot of work on remote Unix servers, so SSH is one of the most important programs I use everyday. Despite using SSH so extensively, I still discover new things I can do with it from time to time. Some of these features are really cool.
There’s a difference between simply just using a tool extensively, and being an expert with the tool. I fall in the former category. I do consider myself a power user. I use SSH not just for remote logins, but also for unattended file copies, command execution, file/directory synchronisation, port tunnelling, and more. I know pretty much most things on this 25 Best SSH Commands / Tricks post.
Over the years, while doing the same old things with SSH over and over again, I sometimes will wonder if there is just a better way to do what I’m doing. I started using SSH since its beginnings, well over 20 years ago. The problem with “old users” like me is that we are sometimes unfamiliar with new features that get added in later times. There are two important features that I want to mention. They deal with secure remote access to intranet resources
SOCKS Proxy
The first is that SSH has a built-in SOCKS 5 proxy. Power users are probably familiar with setting up port forwarding to get around firewalls. Port forwarding can be used with many applications, but one of the common uses is with a web browser to access a remote web server hidden behind a SSH server. I use port forwarding in lieu of a VPN to access intranet web servers.
Port forwarding isn’t difficult to setup, but it is tedious when you need to work with a variety of remote services. If you need to access five remote websites, then you’ll need five port forwarding rules.
SOCKS proxies are much more convenient to use. They work like a HTTP web proxy. A web browser connects to and uses the proxy to access Internet content. SOCKS proxies, however, are more flexible, because it can be used for any TCP network connection on any port. The client side application, however, needs to support SOCKS proxies.
The way I use SOCKS with my web browser is like this. I use Firefox, create a new, separate, profile and set that up to use a SOCKS 5 proxy. This way, I can still choose to run Firefox as normal, without a proxy, by running it with the default profile. Whenever I need to tunnel my web access through a SOCKS proxy, I simply launch Firefox with the second profile.
There’s a reason why I use Firefox for this. Google’s Chrome web browser is my primary web browser. Chrome, however, doesn’t have its own proxy configuration; it uses whatever the operating system has been setup to use. I can change the operating system’s configuration, but it is troublesome when I don’t want SOCKS to be a default system-wide setup. Firefox, thankfully, has its own proxy configuration.
I use a separate Firefox profile for proxy web access. To create a new profile, start Firefox with the -p argument. Firefox will launch with the Choose User Profile screen from which you can create a new profile, or choose an existing profile to use. Also from that screen, you can tell Firefox to always ask you to choose a profile to use every time it starts, so you don’t have to run it with the -p argument.
On the SSH end, connect to your favourite SSH jump host with the -D xxxx argument. E.g.:
ssh -D 5000 user@server.com
This tells SSH to connect to the server, and start up a SOCKS proxy listening on port 5000. Your web browser should then be configured to use a SOCKS proxy on localhost at port 5000.
As I mentioned earlier, SOCKS can work with other protocols. The client-side application, however, has to support SOCKS proxy. Using SOCKS, I can easily bypass the need to use a VPN client, and simply use SSH to connect with any service that is accessible from the remote SSH server.
Jump Host
The next feature is also related to remote access to services protected from direct Internet access. When I’m working out of office, I often find myself having to SSH to server A, then from there SSH to server B, and then, maybe, on to server C. It is tedious if you have to do that many times.
It turns out SSH supports a built-in feature to navigate SSH jump hosts. Run SSH with the -J argument specifying the jump host. E.g. if I want to get to b.server.com, but first have to hop through a.server.com, then this is what I need to do:
ssh -J a.server.com b.server.com
I can specify user names and port numbers on the server specification for the jump host, and I can also string multiple jump hosts together. E.g. if I need to go through a.server.com first, then b.server.com, before getting to c.server.com which is ultimately where I want to login to, then here’s what I’d do:
ssh -J user@a.server.com:5022,b.server.com c.server.com
If you thought that longish command would be rather troublesome to keep typing each time, you can always put the arguments into ~/.ssh/config using the ProxyJump configuration keyword.
An important part of IT security strategy is to protect important assets from direct Internet access. We want to put additional security access controls in front of these important assets. This is why you have VPNs and jump hosts. This usually means a certain level of inconvenience.
With the above tricks, I can do without traditional VPNs. I can take back control and make secure remote access easier to manage.