Zero-Trust SSH Access

SSH Access via Zero Trust

SSH by its very nature is end-to-end encryption with strong protection against Man-In-The-Middle attacks. All servers need to be accessible via SSH to be manageable, often by external users (e.g. vendors, outsourced NOC, etc). However, despite SSH being strong on encryption it is challenging on accessiblity. The servers are typically on private networks (e.g. Virtual-Private-Cloud VPC, internal network VLAN’s, etc). Making them directly accessible to the Internet can be dangerous (we would have to somehow police that all users have passphrases on their keys, that we don’t have passwords allowed, etc.). SSH jump-boxes add a step to the workflow, are difficult to ssh-port-forward and scp through. VPN access is difficult to secure on a per-server basis, often being all-or-none.

In this guide we will setup the Agilicus Zero-Trust Network Access to directly access arbitrary SSH servers. The users will see them as being directly Internet connected. The users will have zero configuration (after the initial setup). Users can be individually authorised on a per SSH server basis. Additionally, users can be federated for identity by any upstream identity provider, allowing an external vendor to be identified by their own corporate Azure Active Directory, an independent contractor via their Google login.

The data flow is such that the SSH TCP session is intact from the client to the server: the hostkeys are unaltered, SSH anti-tamper mechanisms are unperturbed. SFTP just works.

The end user can use any SSH client (ssh command line, mobaxterm, putty, etc), with no complicated config to remember. The system administraor can gate access on/off per user, and, see an audit trail of who has accessed what, when, from where.

SSH Access Setup

Note: you can use a site-to-site VPN via IPSEC, or use the onsite Agilicus Secure Exposed Agent for each pool of servers. These instructions assume the latter.

Network Resource Setup

You configure each SSH server as below:

Fields:

• Service Name: This will appear in audit logs
• Hostname: This name will be as it would appear in the network of the “Via Connector”. This is usually an internal hostname in your network. You can use the “Override IP” to allow for hosts which do not resolve.
• Port: This is typically 22 for SSH
• Override IP (optional): If present, this IP will be used by the Connector to find the SSH server

The remainder of the columns should be left default.

User Client Setup

The intructions vary per ssh client. Generically, the user must download the Agilicus Secure Exposed Agent to their device (on Linux, we recommend ~/bin, on Windows, we recommend %APPDATA%,). This software will automatically update itself and also automatically configures itself from the API.

A set of binaries are available for download:

• Linux X86_64
• Linux ARM
• Linux MIPS Big Endian
• Linux MIPS Little Endian
• Microsoft Windows
• MacOS Darwin (X86-64)

Generically, we now must configure a ProxyCommand. This is simplest if you have used a prefix on your service names (e.g. ‘myco-foo’, ‘myco-bar’). We would then edit ~/.ssh/config as:

Host myco-*
ProxyCommand ~/bin/agilicus-agent wscat --oidc-issuer https://auth.MYCNAME --hostname %h --port %p

At this time, when the user types ‘ssh myco-foo’ their ssh client will connect (via stdin) to the ~/bin/agilicus-agent. It will in turn ensure it has a valid access token for the user. This might entail opening your browser (automatically) and signing in, optionally with multi-factor authentication. Once complete, it will lookup the coordinates of the destination and forward the traffic there. The destination will confirm the user is authorised, and then allow/deny.

Similarly the user can run ‘ssh’, ‘scp’ ,’sftp’ as if ‘myco-foo’ where directly internet connected.

Specific SSH Client Configuration

• SSH Command Line
• MobaXterm
• Putty

1. Download agilicus-agent to a location the user has read/write access to, make it executable
2. Add a line to ~/.ssh/config (either 1 per service, or, using patterns) as below:

Host myco-*
ProxyCommand ~/bin/agilicus-agent wscat --oidc-issuer https://auth.MYCNAME --hostname %h --port %p

In MobaXterm start a session as ‘shell’

curl https://www.agilicus.com/www/releases/secure-agent/stable/agilicus-agent.exe > $USERPROFILE/AppData/Local/Microsoft/WindowsApps/agilicus-agent.exe

Now we have the Agilicus agent downloaded and on the path. We can setup .ssh/config in the same way as previously:

Host myco-*
ProxyCommand ~/bin/agilicus-agent wscat --oidc-issuer https://auth.MYCNAME --hostname %h --port %p

Note: at this time the ‘shell’ we can ‘ssh myco-foo’ directly. However, the ‘tabbed sessions’ view does not appear to support ProxyCommand. As a workaround, create a new tabbed session, use type=shell, and make the command-line be ‘ssh myco-foo’. This will allow direct launching individual ssh hosts from the tab interface.

Download the Agilicus Agent:

In the Connection/Proxy section, add a line, changing the path and issuer according to your environment.

PATH TO AGILICUS\agilicus-agent.exe wscat --oidc-issuer https://auth.MYCNAME --hostname %host --port %port

The host and port will be inherited from the details entered in the session page.