Bastion Host vs VPN vs Public SSH: Choosing the Right Access Model

Bastion host vs VPN vs public SSH is a decision about how administrators and trusted users reach cloud servers, private networks, databases, and internal tools.

The right model depends on what is being protected, who needs access, how many resources must be reached, and what the team can operate consistently. A simple development VM and a production environment with databases, Windows systems, and multiple administrators need different access boundaries.

The goal is not to remove all access. The goal is to create deliberate access: named users, limited permissions, private services, reviewable paths, and recoverable administration.

Why access architecture matters

Every administrative path is a security boundary.

Common access targets include:

• Linux SSH administration
• Windows RDP access
• private databases
• internal dashboards
• monitoring systems
• backup systems
• application management interfaces

The access model should answer:

The best access model is the one the team can maintain, monitor, and review.

Public SSH: simple but directly exposed

Public SSH means the SSH service is reachable from the internet.

Example:

ssh user@server-ip

This is common for developers because it is fast and simple. A new Linux VM can be deployed, an SSH key added, and administration can begin immediately.

Public SSH is not automatically insecure. The risk comes from unmanaged exposure.

Public SSH baseline controls

Use:

• SSH keys instead of passwords
• unique keys per administrator
• disabled password login where practical
• restricted firewall rules
• regular patching
• login monitoring
• key removal during offboarding
• no public database exposure

When public SSH becomes a poor fit

Review the model when:

• multiple administrators need access
• contractors or external users are involved
• the workload stores sensitive data
• the server supports revenue operations
• the environment contains multiple private services
• access history must be audited

A simple access model can be secure, but temporary solutions often become permanent without review.

Bastion host: controlled SSH entry

A bastion host is a dedicated access gateway used to reach private servers.

Instead of exposing SSH on every server:

Admin device → Bastion host → Private servers

The bastion becomes the controlled entry point.

When a bastion fits

Use a bastion when:

• multiple Linux servers need administration
• production servers should not expose SSH publicly
• database administration requires controlled access
• several administrators need a common access path
• consultant or MSP access must be tracked

Benefits include:

Bastion responsibilities

A bastion is a security boundary and should remain simple.

Maintain:

• hardened OS
• minimal installed services
• patching
• individual user accounts
• SSH key management
• access logs
• firewall restrictions
• emergency recovery access

Do not turn the bastion into an application server, database host, or general-purpose utility machine.

VPN: private network access

A VPN creates a private path between approved users and internal resources.

Example:

Admin device → VPN → Private network → Servers and services

VPNs are useful when users need access to multiple private systems rather than only one SSH endpoint.

When a VPN fits

Use a VPN for:

• multiple private servers
• private databases
• internal dashboards
• Windows RDP workloads
• distributed teams
• office-server replacement scenarios
• internal tools

A VPN is often the better choice when Linux, Windows, databases, and applications all need private connectivity.

VPN responsibilities

A VPN should not become a flat trusted network.

Maintain:

• named users
• strong authentication
• limited routes
• network segmentation
• device controls where needed
• access reviews
• logs
• offboarding procedures

Being connected to a VPN should not automatically mean unlimited access.

Bastion vs VPN vs Public SSH comparison

Simple rule:

• Public SSH optimizes speed.
• Bastion optimizes controlled SSH access.
• VPN optimizes private resource access.

Choose by team and workload

Solo developer

A single developer managing a test VM may use public SSH with strong keys and basic firewall rules.

Small production team

A team with multiple administrators should move toward:

• unique identities
• access reviews
• restricted ports
• bastion or VPN where appropriate

Distributed team

Remote teams often benefit from private access models because users connect from different locations and devices.

MSP or consultant access

External access requires:

• named users
• expiration policies
• audit logs
• scoped permissions
• clear ownership

Production databases

Databases should normally remain private. Use a private path through VPN, bastion, or internal networking rather than exposing database ports publicly.

Modern private access models

Access is no longer limited to traditional VPNs and bastions.

Identity-based private access tools and mesh VPN solutions can simplify access for distributed teams.

These models can help when:

• users work from multiple locations
• contractors need controlled access
• RDP should not be public
• internal tools need identity-based access
• the team wants simpler private networking

The principles remain the same:

• identify users
• restrict resources
• review permissions
• remove access when no longer needed
• monitor important activity

The tool changes. The security model does not.

Practical architecture patterns

Simple Linux VM

Admin device → Restricted SSH → Linux VM

Good for low-risk workloads.

Controls:

• SSH keys
• firewall rules
• patching
• backups
• monitoring

Production Linux environment

Admin device → Bastion → Private application/database servers

Good when multiple servers exist.

Controls:

• hardened bastion
• private servers
• logging
• individual accounts

Mixed Linux and Windows environment

User device → VPN/private access → Linux, Windows, databases

Good for business environments.

Controls:

• identity-based access
• network segmentation
• private services
• RDP restrictions

How this applies on Raff

Raff Cloud Servers support practical access design for Linux and Windows workloads.

Common patterns:

Raff provides Linux and Windows Cloud Servers, firewall controls, private networking options, snapshots, backups, and full administrator control.

Start simple, reduce public exposure, keep private services private, and introduce bastion, VPN, or identity-based access when the workload requires stronger boundaries.

Access model checklist

Before choosing an access model, confirm:

Identity

• Every administrator has a named account
• Shared credentials are avoided
• Offboarding removes access
• Access ownership is clear

Exposure

• Public ports are documented
• Databases are private
• RDP is restricted
• SSH exposure is intentional

Operations

• Keys and credentials are reviewed
• Logs are available
• Emergency access is documented
• The team can operate the chosen model

Architecture

• Public traffic is separated from admin traffic
• Private services use private paths
• Permissions follow least privilege
• Access is reviewed as the team changes

Conclusion

Public SSH, bastion hosts, and VPNs solve different access problems.

Public SSH is fast and simple but requires careful hardening. Bastion hosts provide controlled SSH access to private servers. VPNs provide private connectivity to multiple internal resources.

Choose the simplest model that provides the required security boundary. As workloads become more important, move from direct access toward controlled private access, identity management, and regular reviews.

Sources

• NIST Zero Trust Architecture
• Raff Private Cloud Networks
• Raff Cloud Servers