Regalis Technologies

Using SSH - the right way

Introduction

The Secure Shell Protocol (SSH) is probably the most used protocol by devops/sysadmins around the world.

Most people think of the SSH as a method of accessing a shell on a remote host. The fact is that this is just one tiny usage example of the SSH. Some other examples include:

• local port forwarding - connections to the given TCP port or Unix socket on the local (client) host are to be forwarded to the given host and port, or Unix socket, on the remote side.
• remote port forwarding - connections to the given TCP port or Unix socket on the remote (server) host are to be forwarded to the local side,
• local dynamic application-level port forwarding (SOCKS proxy),
• remote dynamic application-level port forwarding (SOCKS proxy),
• tunnel device forwarding between the client and the server (L3 tun device) - Virtual Private Network (VPN) tunnelling using the tun network pseudo-device, allowing two networks to be joined securely,
• accessing and/or mounting a remote filesystem.

Being familiar with all the above features is absolutely essential for any SSH user - both for the sake of convenience and for the security.

Which client should I use?

Well, the answer is simple - you should use the simplest and the most powerful one - the text-based ssh from the OpenSSH suite. It follows the KISS principle and, as a result - enables a user to use simple, straight and well-known tools to perform even very complex tasks.

What about the PuTTY and similar tools? 🐒

The following example should be both sufficient and self-explanatory...

Let's say we have a gpg-encrypted, compressed tar archive stored on the local station. We need to copy a single file called secret.config from the archive above directly into the /etc/xyz/ directory on the host host.lab.regalis.tech. What's more - the host.lab.regalis.tech is not directly accessible from our local station; instead, we need to use a jump host (let's say jump.regalis.tech).

What could go wrong?

The amount of things which could go wrong during execution of this task could be overwhelming. To name just a few of them:

• the user may come up with the idea to decrypt the gpg archive locally - this will leak it's content into the non-volatile memory of the local station,
• the user may copy the previously decrypted file secret.config to the jump host,
• the user may open a shell on the jump host, and then leak his credentials to the destination host (in the worst case scenario, the user may copy his SSH private keys to the jump host).

Depending on the context, any of the user's action above may lead to a serious security incident. The key is to be aware of what could go wrong, this is possible only if the user has deep knowledge about the protocols and the internals of tools he uses.

Unfortunetly, it is very likely that laziness, and desire to take shortcuts are one of the main reasons why someone chooses these types of tools (PuTTY etc.). It is widely recognized that it is simply not possible to be good at something if one is looking for shortcuts.

I strongly advice anyone not to follow this path.

A better solution

We can easly solve this task with the ssh executed from the local station:

1
2
3

$ gpg --decrypt archive.tar.gz.gpg | \
    tar --extract --gzip --file - secret.config | \
    ssh -J jump.regalis.tech host.lab.regalis.tech 'cat > /etc/xyz/secret.config'

What is very importat to notice is the fact that the solution above is both secure, efficient and a convinient way to perform these kind of operations. It does not start (or even require to start) the shell on the jump host, communication is encrypted, and the secret.config file has not been leaked into the non-volatile memory (neither on the local machine, nor on the jump-host).

The SSH series

This was an introduction to the series about the Secure Shell Protocol, the next articles will cover the following topics in details:

• configuring the ssh client,
• using different methods of authentication,
• working with jump hosts,
• using local/remote port forwardings,
• using dynamic, application-level port forwardings,
• configuring the ssh server,
• designing and implementing a reasonably secure jump host,
• jump host design anti-patterns,
• top SSH myths.