What does it take to secure SSH access if you’re not using a VPN? In this blog we’ll answer that question, plus take a closer look at how to apply additional levels of security to SSH access when using a ZTNA solution like Twingate.

Using Twingate to govern access to SSH resources

It is very easy to use Twingate to govern network-level access. Supposing you have a server running SSH in your internal network and you'd like to provide access to a couple of administrators you can add the server as a resource in Twingate and assign a couple of users to have access to it.

Without Twingate, no one outside the network will be able to establish a network connection to the resource. And with Twingate, only the users you've granted access can establish a connection. This satisfies the principle of least privileged access.

Fine-grained access to network resources such as SSH (or almost any TCP/UDP service at the Transport Layer) is possible without requiring us to install or run anything special on the servers. For many of our users this simplicity is part of why they select Twingate for their Zero Trust remote access requirements.

Out-of-the-box however, Twingate doesn't provide any mechanism to authenticate you at the Application Layer. If you grant a user access to an SSH service, the user will still need credentials such as a username/password or an SSH key to actually log in to the device. From the users we've spoken to, this is not a problem in practice; they are used to adding SSH keys to their servers. But we often hear that SSH access management can be a concern - we'll look at options for this later in this post.

The addition of Twingate to their existing process provides three quick-wins:

1. Easily revoke access to a server by removing access to the resource - making any SSH key useless immediately and allowing time for administrators to remove credentials on the server.

2. Users can use their existing SSH client and other tools with no reconfiguration required.

3. Prevent brute-force attacks on the SSH host since it does not have to be accessible over a public IP address or DNS. Without Twingate here, fail2ban becomes an almost essential need for some level of protection.

And once again, these benefits are available without needing to install software on every SSH server in an estate.

Application layer authentication

But what if we also need application-layer credential management for our users? In the SSH case that can mean governing what users exist on the host and what credentials can be used to access them.

There are several options for this and we come across customers using or evaluating ones such as StrongDM and the Open Source Teleport, amongst others. These solutions do need more work to setup with additional client-side and server-side configuration required. For this article however we're going to look at an excellent solution we've been testing within Twingate called Smallstep.

Twingate + Smallstep

Smallstep enables security teams to generate short-lived credentials for users to access specific resources such as SSH. These credentials can be generated following an authentication challenge against an Identity Provider such as Okta or Google Workspace.

So let's consider what we'd like to achieve in a fictitious but real-world scenario:

• For regular users that access internal web applications and network shares, Twingate already provides secure, controlled access.

• For development teams they're going to manage SSH keys to development environments themselves and Twingate allows security teams to isolate those development environments from the public Internet.

• For production systems, SSH access has to be carefully managed. Not only would we like Twingate to protect network access, we'd like our SSH users to perform a further security challenge to gain access.

This last point is fairly significant - having additional layers of security challenge proportionate to the risk of a specific resource or system is a universal best practice. At the same time, having onerous security requirements to access low-risk systems might provide questionable security benefit and create a poor user experience. At Twingate, user experience is central to our product design because not only does usability drive better adoption, it minimizes the chances of someone actively working around rules or systems they find cumbersome.

With Twingate and Smallstep together, security teams can carefully tune the level of security applied to different systems. And where Smallstep is added, a bad actor would have to breach 2 independent systems - one that governs network access (Twingate), and another that governs credentials (Smallstep) - before they could gain unauthorised access to a protected system.

You might notice that in the diagram above there is a potential weakness - the IdP ultimately provides authentication for both systems. Of course, an IdP will always be a critical component of any security infrastructure but there additional security checks you can leverage to mitigate risk in this scenario - for instance by layering IdPs or leveraging Twingate’s built-in device posture checks and WebAuthn MFA.

Find out more and get started

Twingate is available with a free Starter tier and Smallstep is available as both self-hosted and as a commercial offering (SaaS). For more technical details and getting started steps please visit our docs page.

Docs Page - Twingate with Smallstep