SSH is one of those tools that are used automatically by the developers.
Want to see what's going on with the server?
ssh user@server
Easy.
However, public SSH access usually requires exposing port 22 to the web, setting up firewalls, limiting IP addresses, or adding a bastion host before the internal network.
It will work, but as you add more infrastructure, it will become harder to manage your remote access.
There is an alternative, however – to keep the servers private and limit their access with a Zero Trust network.
Why Public SSH Access May Be an Issue
Publicly accessible SSH server is always exposed to the internet.
Although authentication is done properly, there is always a need to think about firewalls, credentials, authorized users, IP address restrictions, and monitoring.
One of the solutions to reduce the exposure is to allow SSH access from a specific set of IP addresses.
However, it will not be convenient for remote developers.
Bastion Host could also be considered another popular choice:
Developer
↓
Bastion Host
↓
Private Server
Here we decrease exposure of the internal servers, however, the bastion becomes another infrastructure component that needs to be protected and maintained.
But What If There Was No Need for SSH on the Server from the Outside?
Instead of exposing SSH externally, let us picture the developer and the server communicating via a private encrypted channel.
Developer Laptop
↓
Private Encrypted Channel
↓
Production Server
We have no need to expose SSH while the server remains behind its firewall, and devices access the server via a private encrypted channel.
It is at this point when solutions like Zero Trust Network Access start getting interesting.
QuickZTNA works by connecting devices and infrastructure via WireGuard-based private mesh while applying Zero Trust security controls to access.
And the whole point is not to provide yet another tunnel but to control what and who accesses what.
**
Being Connected Does Not Necessarily Mean Having Access to Everything**
If five developers are connected to the company's internal infrastructure.
It does not necessarily mean that all of them are automatically granted SSH access to every single server.
First developer requires access to the staging environment.
Second developer requires access to the production environment.
Contractor requires a dev environment only.
Zero Trust approach may provide more accurate permissions.
For instance:
Developer + Approved Device + SSH + Production = Allow
Contractor + SSH + Production = Deny
Access policies implemented by QuickZTNA Zero Trust follow the principle of least privileges: users are granted the access they really need instead of the access to the entire network.
*What About the Setup?
*
Security upgrades are quite useless if their implementation requires one person full-time job.
For small teams of engineers, maintaining such things as VPN gateways, bastion hosts, firewall configurations, and networking could lead to unnecessary complexity.
One way to simplify is by connecting authorized devices directly to the managed private network.
The QuickZTNA Quickstart demonstrates how the administrator can generate an authentication key, install the client and connect the device without manually exchanging WireGuard keys or configuring inbound firewall ports.
It would be especially helpful for small DevOps teams that need to have access to their private infrastructure without maintaining any additional gateway infrastructure.
**
Conclusion**
SSH isn’t the problem itself.
The real question here is how to make SSH reachable.
Ports, IP allowlists, and bastions could help to solve certain aspects of remote access problems.
Zero Trust networking provides an alternative approach: keep your infrastructure private, identify who and what is asking for access, and provide access to required resources only.
From the point of view of developers, this changes the question:
“How do I expose this server safely?”
to
“Do I really need to expose this server?”
Top comments (0)