A bastion host is a hardened administrative gateway placed between an administrator and private servers. A VPN creates authenticated private-network reachability. Public SSH connects directly to an internet-routable server. The right model depends on how many systems and protocols administrators need, how much network reachability they should receive, and how easily the team can review and revoke access.
For Raff Technologies workloads, the most useful decision is not simply “bastion host vs VPN.” It is: what is the narrowest administrative path that still lets the team operate Linux, Windows, databases, and internal services reliably?
Use restricted public SSH for a small, low-risk Linux environment with tightly controlled sources. Use a bastion host when private servers mainly need one controlled SSH or RDP entry point. Use a VPN when administrators need several private protocols or services from their workstation. Larger or higher-risk environments can combine VPN access with a bastion for an additional privileged boundary.
Bastion host vs VPN vs public SSH: quick answer
| Access model | Best fit | Main advantage | Main risk |
|---|---|---|---|
| Restricted public SSH | One or a few low-risk Linux servers | Lowest operational complexity | Management endpoint remains public |
| Bastion host | Several private servers, focused SSH/RDP administration | Centralizes administrative entry | Bastion can become over-privileged |
| VPN/private access | Mixed SSH, RDP, databases, dashboards, internal APIs | Gives tools private network reachability | Flat VPN routes can expose too much |
| VPN + bastion | Sensitive production or customer environments | Separates network entry from privileged server entry | More components to operate and recover |
A useful rule is:
Choose the smallest access surface your team can operate consistently, then separate network reachability from actual privilege.
What is a bastion host?
A bastion host is a deliberately hardened server or gateway used as the administrative entry point to systems that otherwise remain private.
Administrator ↓ restricted access Bastion host ↓ private network Application VM / database / internal server
Instead of exposing SSH or RDP on every target server, the team exposes or privately reaches one controlled gateway and then connects onward over private paths.
A bastion can reduce the number of public administrative endpoints, but it also concentrates trust. If every administrator shares one credential and the bastion can reach every server, the architecture has centralized risk rather than reduced it.
A sound bastion baseline includes:
- a supported, minimal operating system;
- only required services;
- named administrator accounts;
- individual SSH keys or approved authentication methods;
- restricted inbound reachability;
- narrow private routes and target firewall rules;
- patching and monitoring;
- no unrelated application workloads;
- a documented break-glass path.
Treat the bastion as privileged infrastructure, not a general-purpose utility VM.
What is a VPN for remote administration?
A remote-access VPN creates an authenticated network path between an administrator device and approved private resources.
Administrator device ↓ VPN Private network ├─ SSH → Linux VM ├─ RDP → Windows VM ├─ DB client → database └─ HTTPS → internal dashboard
A VPN is usually a better fit when administrators need several protocols or applications rather than only terminal access to a few Linux servers.
The key limitation is that VPN connectivity creates reachability, not authorization. A user who joins the private network should not automatically be able to reach every subnet, RDP session, database, backup system, or customer environment.
Use route scope, target firewalls, operating-system permissions, and service authentication to keep access narrow after the VPN connection succeeds.
Public SSH can still be the right answer for simple workloads
Public SSH means the SSH service itself is reachable through an internet-routable address.
That model can be appropriate when:
- there is one low-risk or disposable Linux VM;
- only one or two named administrators need access;
- stable source IPs can be allowlisted;
- individual SSH keys are used;
- the operating system is patched;
- login activity is monitored;
- no sensitive private services depend on the server.
Public SSH becomes harder to govern when the environment adds more people, servers, databases, customer data, Windows systems, contractors, or audit requirements.
The common mistake is not beginning with public SSH. It is leaving the same exposure model in place after the system grows into production infrastructure.
Bastion host vs VPN: the practical decision
Choose a bastion host when:
- most administration is SSH or controlled RDP;
- target servers should not expose management ports directly;
- a small set of entry points is easier to review;
- broad workstation-to-private-network reachability is unnecessary;
- administrators can work effectively through a gateway.
Choose a VPN when:
- administrators need SSH and RDP plus databases or dashboards;
- several private protocols are involved;
- local administration tools need direct private connectivity;
- private DNS or internal web services matter;
- teams operate from several locations.
Use both when the environment needs separate trust stages:
Administrator ↓ VPN Management network ↓ bastion Sensitive production systems
The extra layer is useful only when it creates a meaningful boundary the team can actually maintain.
Public SSH vs VPN is not a pure either-or choice
SSH and VPN solve different layers of the problem.
SSH authenticates a session to a Linux server. A VPN provides network connectivity.
A common production design is:
Administrator ↓ VPN Private IP of Linux VM ↓ SSH authentication Linux server
In this model, SSH is still the server login mechanism, but TCP 22 does not need broad public exposure.
The better question is therefore:
Should SSH be reached directly from the internet, through a bastion, or over a private access path?
Network reachability is not the same as privilege
Every remote-access model should separate four decisions:
Can reach the network ↓ Can reach this server and port ↓ Can authenticate ↓ Can perform privileged actions
Joining a VPN should not automatically grant database-owner rights. Reaching a bastion should not automatically grant root on every target. A working SSH key should not be shared between unrelated users or automation systems.
Apply least privilege at each layer:
- network route;
- firewall/source policy;
- operating-system account;
- sudo or local Administrator membership;
- database role;
- application authorization.
Use Cloud Firewall Best Practices for the network-policy layer.
A bastion host is not automatically safer
A bastion can become a high-value failure point if it is poorly operated.
Common problems include:
- unrestricted public access to the bastion;
- shared administrator credentials;
- private keys stored on the bastion that unlock every target;
- flat routes across unrelated environments;
- application software installed on the gateway;
- no monitoring or patch ownership;
- no emergency access path if the bastion fails.
Use per-user authentication and target-side authorization where possible. Avoid turning the bastion into a permanent credential warehouse.
A bastion should reduce the number of trusted paths, not become one account with unrestricted reach across the infrastructure.
A VPN is not automatically least privilege
A VPN can also become too broad.
Watch for:
- one shared VPN profile used by several people;
- stale peers after offboarding;
- all users receiving the same routes;
- target firewalls trusting the entire VPN range;
- customer environments reachable from one flat network;
- unmanaged administrator devices with broad production reach.
A VPN should provide the routes required for the administrator's role, then downstream controls should narrow access further.
For MSP environments, design routes and permissions around customer boundaries rather than treating every connected technician as equally trusted.
Windows RDP usually pushes teams toward private access sooner
RDP is a powerful Windows management surface and should receive a stricter exposure model as workload importance increases.
For production Windows administration, prefer:
- VPN or another controlled private path;
- tightly restricted sources when public reachability remains necessary;
- named Windows administrator accounts;
- limited local Administrators membership;
- Network Level Authentication where supported;
- current Windows security updates;
- MFA at the access layer where the selected architecture supports it;
- recurring access review.
Do not use a strong Administrator password as the only control around a broadly public RDP endpoint.
Review Raff Windows VM for the current Windows compute path and Raff VPC for current private-networking options.
Databases and internal tools should normally stay private
Databases, internal dashboards, monitoring interfaces, queues, and backup consoles usually do not need public administration endpoints.
A safer pattern is:
Application VM ↓ private network Database Administrator ↓ VPN or bastion Private database/admin endpoint
Allow only approved application and administrator sources.
If a team prefers to move database operations into a managed service boundary, review the current Managed Databases offering rather than exposing a self-managed database simply for administrative convenience.
Human and machine identities need separate access paths
A CI/CD runner, backup process, monitoring service, and human administrator should not share one SSH key or one privileged account merely because they connect to the same server.
Separate:
- human administration;
- deployment automation;
- monitoring;
- backup and recovery;
- application credentials.
This improves revocation and incident containment. If a deployment credential is exposed, the team should be able to disable it without locking out every administrator.
Small teams should optimize for understandable security
A remote-access design that nobody understands will eventually accumulate permanent exceptions.
Solo developer or disposable workload
Restricted public SSH may remain appropriate when the VM is low risk and the source can be narrowly restricted.
Small production team
A bastion or VPN becomes more useful when several administrators, private databases, or multiple application servers exist.
Mixed Linux and Windows environment
A VPN/private-access model is often easier because one workstation may need SSH, RDP, database clients, and internal dashboards.
MSP environment
Customer separation becomes the primary requirement. Avoid one credential, route, gateway, or private network that gives every technician access to every client.
Use Private Cloud Networking for MSPs for network separation and Secure Remote Access for MSPs for technician-access design.
When should you move away from public SSH?
Revisit the model when:
- a second or third production server is added;
- a database moves to a separate host or managed service;
- Windows/RDP is introduced;
- contractors or MSP technicians require access;
- administrator source IPs change frequently;
- customers ask for access evidence;
- several public management endpoints need independent review;
- one server starts acting as a gateway to other systems.
Use Private vs Public Admin Access for the broader transition decision.
Access lifecycle matters more than the initial architecture
Every model needs recurring review of:
- human users;
- SSH keys;
- Windows accounts;
- VPN peers or memberships;
- administrator groups;
- firewall rules;
- private routes;
- temporary vendor access;
- break-glass credentials.
When someone leaves, remove access across the complete path. Deleting a cloud account is incomplete if an SSH key, Windows user, VPN peer, or database credential still works.
Use Cloud Access Reviews for Small Teams for the governance process.
Break-glass access prevents private administration from becoming a lockout
Bastions and VPNs can fail. DNS, routing, identity systems, or firewall policy can fail too.
Production environments should document an emergency path answering:
- Who may authorize emergency access?
- Which recovery credential or console is used?
- How is that method protected?
- Which systems can it reach?
- How is emergency use recorded?
- What gets rotated afterward?
- How is the normal access path restored?
A break-glass path should remain exceptional rather than becoming the easiest everyday login method.
Recovery testing should include the access path
Restoring a VM is not enough if administrators cannot reach it afterward.
During restore or rebuild testing, verify:
- the expected private network is attached;
- routes and firewall rules exist;
- the bastion or VPN can reach the target;
- SSH/RDP identities remain valid intentionally;
- private DNS resolves correctly;
- emergency console or break-glass access still works.
Use Restore Testing Checklist for Production VMs for the wider recovery workflow.
How this maps to Raff
A Raff access architecture can evolve without hard-coding one model into every server.
Low-risk VM → tightly restricted public SSH Growing production environment → private VPC paths → bastion or approved VPN access Sensitive / multi-customer environment → scoped routes → named identities → target-level authorization → recurring access review
Relevant Raff paths to review include:
- Raff Cloud Servers;
- Windows VM;
- VPC;
- Security;
- Site-to-Site VPN;
- Data Protection;
- Managed Databases.
Use the live product and pricing pages for current availability, limits, and commercial values. This guide intentionally avoids hard-coded VPN pricing, peer limits, tunnel pricing, or network-capacity figures because those are mutable product details rather than durable access-architecture principles.
Raff provides infrastructure building blocks. Your team still owns operating-system users, SSH keys, Windows accounts, VPN membership, target permissions, offboarding, and workload-level authorization.
