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 administrator 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.
SSH Resource Setup
4 steps:
- Select the connector (the site on which the underlying SSH resource exists)
- Create a name for the SSH resource. This will appear as a valid hostname and must be unique within your sub-domain. Feel free to use a pattern, e.g. ‘site-host-ssh’.
- Select the hostname/IP and port that the SSH server is on in that remote network.
- Assign permissions (who can use this SSH resource)
The underlying SSH resources will also show up under Network Resources
Using the SSH Resource
If you have not done so, install the Agilicus Launcher on your desktop (Windows, Linux Mac) from profile (https://profile.YOURDOMAIN). The Launcher support runs on demand, it is not a service. It will automatically configure OpenSSH (Windows, MAC, Linux), or Putty (Windows).
Note: The Launcher will configure OpenSSH if the file ~/.ssh/config exists. If you have not used SSH before, you might need to create this file.
The SSH access operates using the SSH ProxyCommand feature. It will create an entry such as:
Host <RESOURCENAME>
ProxyCommand ~/bin/agilicus-agent wscat --oidc-issuer https://auth.MYCNAME --resource-name %h --port %p
Thus when a user runs ‘ssh <RESOURCENAME>’, they will transparently connect to it. Periodically, a browser will popup to confirm the user identity (optionally with multi-factor authentication).
Similarly the user can run ‘ssh’, ‘scp’ ,’sftp’ as if ‘myco-foo’ where directly internet connected.
Specific SSH Client Configuration
The Launcher, above, will automatically configure your client. If you wish, you may make manual configuration inspired as below. You may also wish to use a wildcard, so that e.g. the following works, and thus ssh <ANYTHING>.MYDOMAIN follows your pattern.
Host *.MYDOMAIN
ProxyCommand /home/don/.agilicus/agilicus-agent wscat --oidc-issuer https://auth.dbt.agilicus.cloud --resource-name $(echo %h |
sed -e 's?\..*??'g) --port 22
- Download agilicus-agent to a location the user has read/write access to, make it executable
- Add a line to ~/.ssh/config (either 1 per service, or, using patterns) as below:
Host RESOURCENAME
ProxyCommand ~/.agilicus/agilicus-agent wscat --oidc-issuer https://auth.MYCNAME --resource-name %h --port %p
Now we have the Agilicus agent downloaded and on the path. We can setup .ssh/config in the same way as previously:
Host <RESOURCENAME>
ProxyCommand ~/.agilicus/agilicus-agent wscat --oidc-issuer https://auth.MYCNAME --resource-name %h --port %p
Note: at this time the ‘shell’ we can ‘ssh RESOURCENAME’ 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 RESOURCENAME’. 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. Unfortunately, Putty cannot expand environment variables. In the xample, where we have %LOCALAPPDATA%, find the proper value for your system (typically
echo %LOCALAPPDATA%
C:\Users\don\AppData\Local
Your command will look as below, please fill in %LOCALAPPDATA%
%LOCALAPPDATA%\Agilicus\agent\agilicus-agent.exe wscat --oidc-issuer https://auth.MYCNAME --hostname %host --port %port
- Create a session. The hostname will be as in the ‘host’ column (column 2) in the networks tab in the Admin portal.
- Set a Local proxy as below.
- Save the session


Related Configuration
Return to Product Configuration
- Locked-Down Networks Certificate Revocation
- Signup: Firewall Configuration
- Sign-In Errors
- Geo-Location-Based Access Control
- Time Synchronisation
- Agent Connector Sign-In
- Resources – Overview, Concepts
- Connect to VTScada – Adding a Web Application
- Web Application Security
- Administrative Users
- Define Application: Proxy
- Authorisation rules
- Agent Connector Install: Raspberry Pi
- Real VNC & Raspberry Pi
- Kubernetes Agent Connector Install
- Linux, FreeBSD, Embedded Agent Connector Install
- Agent Connector Install: Ubiquity EdgeRouter X
- Audit Destinations
- Agent Connector Install: Netgate SG-1100 pfSense
- Identity Group Mapping
- Billing
- Auto-Create Users From Specific Domain With Google Workplace
- Organisation
- Authentication Audit
- Authentication Issuer – Custom Identity
- Signup
- Microsoft ClickOnce
- Groups
- Agilicus Agent Windows Cluster
- Launchers
- Forwarding
- Usage Metrics
- Service Accounts
- Connectors
- Identity & Authentication Methods
- Content Security Policy
- Users
- Sign-In Theming
- Sign in With Apple
- Azure Active Directory
- Sign in With Microsoft
- Agilicus Agent (Desktop)
- Agent-Connector
- Zero-Trust SSH Access
- Theory of Operation: CNAME + DOMAIN
- Zero-Trust Desktop Access
- Command Line API Access
- Applications
- Permissions
- Profile
- Multi-Factor Authentication
- Authentication Rules
- Application Request Access
- OpenWRT Agent Connector Install
- Synology Agent Connector Install
- Authentication Clients
- Authentication Rules
- Shares
- Services
- Resource Permissions
- Resource Groups
- Legacy Active Directory