Bastion host vs VPN vs public SSH is a decision about how administrators reach cloud servers, private networks, databases, and internal tools.
The right access model depends on what you are protecting, how many people need access, and how much operational overhead your team can realistically maintain. A solo developer testing one VM does not need the same access design as a small business running a production database, a Windows remote desktop workload, or an office-server replacement environment. Raff Technologies has deployed 10,000+ VMs for 1,000+ customers, and the safest access patterns are usually the ones teams can operate consistently.
This guide supports Raff’s Private vs Public Admin Access and Cloud Security Fundamentals guides. It compares public SSH, bastion hosts, VPNs, and related private access patterns so small teams can choose an access model that reduces exposure without creating unnecessary complexity.
Why the Access Model Matters
Admin access is one of the most important cloud security decisions because it defines who can reach your infrastructure and how.
That access may include:
- SSH into Linux servers,
- RDP into Windows servers,
- access to private databases,
- access to internal dashboards,
- access to monitoring tools,
- access to backup systems,
- or access to production application servers.
Every admin path creates risk. If SSH is public, it can be scanned. If RDP is public, it can be targeted. If a VPN is too broad, users may reach more systems than they need. If a bastion host is poorly maintained, it can become a central point of failure.
The goal is not to eliminate all access. The goal is to make access deliberate.
A good access model should answer five questions:
| Question | Why it matters |
|---|---|
| Who needs access? | Prevents broad or shared access |
| What do they need to reach? | Defines the scope of the access path |
| How sensitive is the workload? | Determines how much exposure is acceptable |
| Can the team operate the model? | Prevents complex designs nobody maintains |
| How will access be reviewed? | Prevents stale keys, users, and credentials |
Small teams should not choose an access model only because it sounds secure. They should choose the model they can configure, document, monitor, and review.
The Access Model Decision Framework
Public SSH, bastion hosts, and VPNs solve different problems.
Use this framework before choosing one.
| Scenario | Public SSH | Bastion host | VPN |
|---|---|---|---|
| Solo developer testing one Linux VM | Often acceptable | Usually unnecessary | Usually unnecessary |
| Temporary staging server | Acceptable with restrictions | Optional | Optional |
| Production Linux app server | Risky as default | Strong fit | Good fit if more services need access |
| Multiple private Linux servers | Hard to manage | Strong fit | Good fit |
| Production database | Not recommended | Good if SSH-based admin is needed | Strong fit for private access |
| Internal dashboard | Usually unnecessary | Possible | Strong fit |
| Windows RDP workload | Public RDP is risky | Less common for RDP | Strong fit with proper scope |
| Small distributed team | Harder to control | Good for SSH-heavy teams | Strong fit |
| MSP or consultant access | Risky without auditability | Strong fit | Strong fit |
| Compliance-sensitive system | Not enough alone | Strong fit with logging | Strong fit with identity controls |
A useful rule is:
Use public SSH for simple, low-risk, temporary access. Use a bastion host when you need controlled SSH entry into private servers. Use a VPN when users need private network access to multiple internal resources.
That rule is not absolute, but it gives most small teams a practical starting point.
What Public SSH Means
Public SSH means the SSH service on a Linux server is reachable from the public internet.
The simplest example is:
ssh user@server-ip
Public SSH is common because it is simple. A developer creates a VM, adds an SSH key, connects to the server, and starts working.
That simplicity is useful. It is also why public SSH often stays in place longer than it should.
When Public SSH Can Be Acceptable
Public SSH can be acceptable when the workload is simple, temporary, and low risk.
Examples include:
| Situation | Why public SSH may be acceptable |
|---|---|
| Personal test VM | Low business impact |
| Short-lived staging server | Temporary exposure |
| Solo developer project | One known admin |
| Non-sensitive demo server | Limited data and users |
| Early prototype | Speed matters more than access architecture |
Even in these cases, public SSH should not be left unprotected.
A safe public SSH baseline includes:
- SSH keys instead of passwords,
- disabled password login where possible,
- unique keys per admin,
- no shared private keys,
- firewall restrictions where practical,
- no public database ports,
- monitoring for failed login attempts,
- regular patching,
- and key removal during offboarding.
Public SSH is not automatically unsafe. Unmanaged public SSH is the problem.
When Public SSH Becomes a Weak Fit
Public SSH becomes weaker as the workload becomes more important.
Warning signs include:
- more than one or two admins need access,
- the server becomes production,
- customer data is stored on the server,
- the app connects to a private database,
- SSH keys are shared,
- old keys remain after team changes,
- the server supports revenue or staff operations,
- or the team cannot explain who has access.
At that point, public SSH should be restricted further or replaced with a private access pattern.
For broader context, read Private vs Public Admin Access.
What a Bastion Host Means
A bastion host is a controlled entry point used to reach private servers.
Instead of exposing SSH on every private server, the team exposes or privately reaches one hardened gateway. Admins connect to the bastion first, then use it to reach internal servers.
A simple model looks like this:
Admin device → Bastion host → Private servers
The bastion host is not a normal app server. It should be limited, hardened, logged, patched, and treated as a security boundary.
When a Bastion Host Fits
A bastion host fits when a team needs controlled SSH access to private infrastructure.
Good use cases include:
| Use case | Why bastion fits |
|---|---|
| Multiple Linux servers | Centralizes SSH entry |
| Private app servers | Internal servers avoid public SSH exposure |
| Private database admin | Access can be controlled through one path |
| Production workloads | Reduces exposed admin surfaces |
| Multi-admin teams | Easier key and access management |
| Consultant or MSP access | Better auditability and control |
| Environments with private networks | Bastion can bridge admin devices to private resources |
A bastion host is especially useful when the team wants to remove public SSH from production servers without building a full VPN for every user.
Bastion Host Benefits
A good bastion setup can provide:
| Benefit | Why it matters |
|---|---|
| Reduced exposure | Private servers do not need public SSH |
| Central control | One entry point is easier to monitor |
| Better logging | SSH access can be traced more clearly |
| Easier firewall design | Internal servers allow SSH only from the bastion |
| Better team scaling | Access patterns become more standardized |
| Stronger separation | Public edge and private infrastructure stay distinct |
A bastion host does not remove the need for SSH keys, access reviews, or patching. It makes those controls easier to centralize.
Bastion Host Risks
A bastion host also creates responsibilities.
Common risks include:
| Risk | What can go wrong |
|---|---|
| Weak bastion hardening | The access gateway becomes the weak point |
| Shared bastion users | Accountability is lost |
| Stale SSH keys | Former users can still enter private systems |
| Poor logging | The team cannot investigate access events |
| No emergency plan | If bastion access fails, admins are locked out |
| Overloaded role | The bastion runs other services and grows risky |
A bastion should be boring. It should do one job: controlled access.
Avoid running databases, web apps, monitoring dashboards, file shares, and random scripts on the bastion. The more it does, the harder it is to secure.
What a VPN Means
A VPN creates a private network path between a user device and the infrastructure environment.
After connecting, the user can reach private resources based on routing and access rules.
A simple model looks like this:
Admin device → VPN → Private network → Servers and services
VPNs are useful when users need access to more than one private system.
When a VPN Fits
A VPN fits when a team needs private network access to multiple resources.
Good use cases include:
| Use case | Why VPN fits |
|---|---|
| Multiple private servers | Users can reach private IPs |
| Private databases | No public database exposure needed |
| Internal dashboards | Tools stay off the internet |
| Windows RDP workloads | RDP can be restricted to private access |
| Office-server replacement | Staff or admins can reach hosted systems privately |
| Distributed teams | Users connect from different locations |
| MSP support access | Technicians can reach client environments through a controlled path |
A VPN is usually better than public access when the team needs to reach several internal systems, not just one server.
VPN Benefits
A VPN can provide:
| Benefit | Why it matters |
|---|---|
| Private network access | Internal services stay off the public internet |
| Flexible reach | Users can access servers, dashboards, databases, and tools |
| Useful for RDP | Windows remote desktop can avoid broad public exposure |
| Easier for mixed workloads | Linux, Windows, databases, and apps can share one private path |
| Familiar model | Many teams already understand VPN workflows |
VPNs are especially useful when admin access and internal user access overlap. For example, a small business might use a VPN to reach an internal dashboard, hosted Windows workload, and private database environment.
VPN Risks
A VPN can also become too broad.
Common risks include:
| Risk | What can go wrong |
|---|---|
| Flat network access | Users can reach more systems than needed |
| Weak user controls | Shared VPN accounts reduce accountability |
| Poor offboarding | Former users retain private network access |
| No segmentation | Staging, production, and databases sit on one path |
| Device trust issues | Unmanaged laptops can reach private systems |
| VPN downtime | Admins lose access if the VPN is unavailable |
The most common VPN mistake is treating “connected to VPN” as “trusted for everything.”
A safer VPN model should use named users, strong authentication, limited routes, segmentation, logs, and recurring access reviews.
Public SSH vs Bastion vs VPN
Here is the practical comparison.
| Factor | Public SSH | Bastion host | VPN |
|---|---|---|---|
| Setup speed | Fastest | Medium | Medium |
| Operational complexity | Low | Medium | Medium to high |
| Public exposure | Server SSH is exposed | Bastion path is exposed or controlled | VPN endpoint is exposed or controlled |
| Best for | Simple Linux access | Controlled SSH into private servers | Private network access to many resources |
| Team scaling | Weak if unmanaged | Good for SSH-heavy teams | Good for mixed access needs |
| Windows RDP fit | Not applicable | Limited | Strong |
| Database access | Not recommended publicly | Good for admin workflows | Strong for private access |
| Auditability | Depends on server logs | Better centralized access point | Depends on VPN identity/logging |
| Risk if mismanaged | Exposed admin service | Compromised gateway | Overbroad private network access |
| Best maturity level | Solo or simple workloads | Growing production teams | Teams with multiple private services |
The main trade-off is simple:
- Public SSH optimizes for speed.
- Bastion hosts optimize for controlled SSH.
- VPNs optimize for private network reach.
How to Choose by Team Size
Team size changes the access problem.
| Team stage | Recommended access direction |
|---|---|
| Solo developer testing | Public SSH with keys and basic firewall rules |
| Solo developer production | Restricted SSH; no public database; backups enabled |
| Two to five admins | Unique SSH keys, IP restrictions, access reviews |
| Small production team | Bastion or VPN depending on resource scope |
| Distributed team | VPN, Tailscale, or identity-based private access |
| MSP or consultant model | Bastion, VPN, or zero-trust access with logs |
| Regulated workload team | Private access, least privilege, auditability, documented reviews |
A solo developer can often operate direct SSH safely if they are disciplined. A team needs a more structured model because access becomes harder to track.
The moment contractors, support users, or multiple administrators enter the picture, named users and access reviews become essential.
For the review process, read Cloud Access Reviews for Small Teams.
How to Choose by Workload
The workload matters as much as the team.
| Workload | Better access model |
|---|---|
| Test Linux VM | Public SSH with keys |
| Temporary staging server | Restricted SSH |
| Production web app | Bastion or restricted SSH with private database |
| Multiple app servers | Bastion or VPN |
| Production database | VPN, bastion, or private-only access |
| Internal dashboard | VPN or private access |
| Windows RDP server | VPN, Tailscale, or restricted RDP |
| Office-server replacement workload | VPN or private access |
| Backup server | Private access only |
| Monitoring dashboard | Private or strongly authenticated access |
The safest pattern is to separate user traffic from admin traffic.
A website may need to be public. SSH, RDP, databases, backups, and internal dashboards usually do not.
For private network design, read Private Networking in Cloud: Public vs Private Traffic.
Where Tailscale and Zero-Trust Access Fit
The access-model conversation is no longer limited to public SSH, bastion hosts, and traditional VPNs.
Many small teams now use mesh VPNs or zero-trust access tools to reduce exposure without operating classic VPN infrastructure.
Tailscale and similar mesh VPN tools can make private access easier for distributed teams. Instead of exposing SSH or RDP publicly, servers and devices join a private overlay network. Access can then be controlled by identity, device, and policy.
Zero-trust access tools go further by granting access to specific resources based on identity, device posture, policy, and session context.
These models can be useful when:
- the team is distributed,
- contractors need scoped access,
- RDP should not be public,
- private SSH should be easy to manage,
- internal dashboards need controlled access,
- and the team wants less traditional VPN maintenance.
The caution is that these tools still require management. Identities, devices, policies, offboarding, and logs all need review.
The principle does not change: private access is only safe when it is operated well.
Practical Architecture Patterns
Pattern 1: Simple public SSH with hardening
Use this for low-risk Linux workloads.
Admin device → Public SSH → Linux VM
Minimum controls:
- SSH keys,
- disabled password login,
- firewall restrictions where practical,
- no public database,
- patching,
- backups,
- and key review.
This model is simple but should not become the default for sensitive production systems.
Pattern 2: Bastion into private servers
Use this for SSH-heavy production environments.
Admin device → Bastion host → Private app/database servers
Minimum controls:
- hardened bastion,
- named users,
- SSH keys,
- logging,
- internal servers allowing SSH only from bastion,
- no extra services on the bastion,
- and emergency access planning.
This model works well when the team mainly needs Linux server administration.
Pattern 3: VPN into private network
Use this when users need access to multiple private resources.
Admin device → VPN → Private network → Servers, databases, dashboards
Minimum controls:
- named users,
- strong authentication,
- limited routes,
- segmentation,
- logging,
- offboarding,
- and access reviews.
This model works well for mixed Linux, Windows, database, and internal tool access.
Pattern 4: Mesh VPN or identity-based private access
Use this when a distributed team needs lower-friction private access.
Approved device → Mesh/private access layer → Private resources
Minimum controls:
- identity-based users,
- device management,
- ACLs or policies,
- logs,
- offboarding,
- and periodic policy review.
This model can be strong for small distributed teams, but it still needs ownership.
How Raff Fits Access Model Design
Raff Technologies gives small teams practical building blocks for each access model.
For Linux workloads, Raff VMs support SSH key access, full root control, cloud firewall rules, private networking options, DDoS protection, snapshots, backups, and fast deployment. That gives teams a safe path from simple SSH to more controlled access patterns.
For Windows workloads, Raff Windows VMs support Windows Server environments, full administrator access, and RDP. That is useful for Windows business applications, remote desktop workflows, IIS, .NET, MSSQL planning, and office-server replacement use cases. But RDP should be restricted carefully, especially when the Windows VM becomes part of daily business operations.
A practical Raff access path might look like this:
| Stage | Access model |
|---|---|
| First Linux test VM | Public SSH with keys and limited ports |
| Production Linux app | Restricted SSH or bastion |
| Multiple private Linux servers | Bastion host or VPN |
| Private database | No public database access; use private path |
| Windows RDP workload | VPN, Tailscale, or restricted RDP |
| Small business hosted workload | Private admin path plus backups |
| Growing team | Access reviews, named users, documented ownership |
The goal is not to force every user into the most complex model. The goal is to reduce exposure as the workload becomes more important.
On Raff, a simple operating rule works well:
Start with secure basics, restrict public exposure, keep private services private, and move admin access behind a controlled path when the workload becomes production.
Access Model Checklist
Use this checklist before choosing public SSH, bastion, or VPN.
Workload risk
- Is this workload temporary or production?
- Does it store customer or business data?
- Does downtime affect revenue or operations?
- Does it include a database?
- Does it include Windows RDP?
- Does it support staff or customer access?
Team access
- How many admins need access?
- Are contractors involved?
- Are users distributed across locations?
- Can access be tied to named users?
- How will access be removed during offboarding?
- Who owns the access model?
Exposure
- Does SSH need to be public?
- Does RDP need to be public?
- Are databases private?
- Are admin panels private?
- Are firewall rules deny-by-default?
- Are public ports documented?
Operations
- Can the team maintain a bastion?
- Can the team maintain a VPN?
- Are logs reviewed?
- Are keys reviewed?
- Are backups enabled?
- Is emergency access documented?
Decision
- Use public SSH only when the workload is simple and low risk.
- Use restricted SSH when direct access is acceptable but exposure should be reduced.
- Use a bastion when SSH access to private servers needs central control.
- Use a VPN when users need private network access to multiple systems.
- Use Tailscale or zero-trust access when identity-based private access fits team operations.
- Review access regularly no matter which model you choose.
Common Mistakes to Avoid
Mistake 1: Keeping public SSH forever
Public SSH may be fine for the first test VM. It should not remain the default for every production workload without review.
Mistake 2: Using a bastion but not hardening it
A bastion host is a security boundary. It should be patched, limited, logged, and kept simple.
Mistake 3: Giving VPN users access to everything
A VPN should not become a flat private network where every user can reach every server. Scope routes and permissions.
Mistake 4: Forgetting Windows RDP
RDP deserves separate planning. Do not treat it like simple SSH. Restrict it, monitor it, review users, and consider private access.
Mistake 5: Ignoring offboarding
Access should be removed when people leave, projects end, or contractors finish.
Mistake 6: Exposing databases for convenience
Databases should usually stay private. Public database access is rarely the right default.
Mistake 7: Choosing complexity the team cannot operate
A complex access model that nobody maintains can become less secure than a simpler model operated well.
Conclusion
Bastion hosts, VPNs, and public SSH are not interchangeable. They solve different access problems.
Public SSH is fast and simple, but it exposes an admin path directly to the internet. A bastion host centralizes SSH access into private infrastructure and can improve control, logging, and exposure reduction. A VPN gives users private network access to multiple internal resources, but it must be scoped carefully to avoid broad access.
The best model depends on workload risk, team size, access scope, and operational maturity. Small teams should not overbuild on day one, but they also should not let temporary public access become permanent production exposure.
This guide connects into Raff’s Private vs Public Admin Access, Cloud Security Fundamentals, and Cloud Access Reviews for Small Teams guides. If you are designing private traffic paths, read Private Networking in Cloud.
If your team is running Linux or Windows workloads on Raff, start with the simplest safe model: use SSH keys, restrict public ports, keep databases private, protect RDP, review access regularly, and move toward bastion, VPN, or identity-based private access as the workload becomes more important.