SSH is the better choice when you need to secure one administrative service or selected port, while a VPN is the better choice when you need broad device or network connectivity. In one controlled benchmark, WireGuard reached 3.95 Gbit/s versus 1.82 Gbit/s for OpenSSH 9.8 with ChaCha20-Poly1305, but those figures don't make a VPN the right answer for every job.
You're probably dealing with a familiar decision: expose SSH so you can reach a server, or deploy a VPN so a laptop can reach internal systems as if it were on the local network. Both encrypt traffic and authenticate endpoints, but they solve different problems. SSH is primarily an application-layer administration tool. A VPN works at the network layer, creating a path for multiple applications and hosts.
That difference matters more than a product comparison. The practical question isn't which protocol is stronger in the abstract. It's whether the job calls for least-privilege access to one service or the convenience of broader network reach.
| Feature | SSH | VPN |
| Primary scope | Application or selected connection | Device, subnet, or network |
| Typical use | Shell access, file transfer, port forwarding | Remote work, site-to-site access, private network connectivity |
| Traffic coverage | Only configured SSH sessions and forwarded connections | Multiple applications and IP flows |
| Security boundary | User, host, tunnel, and permitted destinations | VPN identity, gateway, routes, and reachable network segments |
| Deployment advantage | Fast for one known service | Better for transparent, broad connectivity |
| Main risk | Over-permissive forwarding or compromised account | Excessive network reach after credential or gateway compromise |
Origins and Core Philosophy
In 1995, administrators at Helsinki University of Technology faced a practical security failure: a password-sniffing attack exposed how easily Telnet and rlogin sent remote-login credentials and session data in plaintext. Tatu Ylönen created SSH to solve that immediate problem, secure access to remote Unix systems. By the end of that year, the software had reached about 20,000 users across 50 countries, showing how broadly the need for protected administration had spread. The historical record of SSH standardization covers that origin and the protocol's later development.
SSH's starting point still shapes its design. It protects a shell session, transfers files, and carries selected connections through an authenticated administrative channel. Port forwarding can extend access to a database or internal web service, but the administrator defines which destination passes through the tunnel. Unrelated traffic stays outside it unless someone deliberately configures otherwise.
VPNs address a broader problem. They create an encrypted network path across infrastructure that cannot be trusted, allowing traffic from several applications or hosts to use the connection. That fits remote employees who need multiple internal services and site-to-site links where networks must communicate without making each application aware of the tunnel.
SSH's secure administration heritage
The IETF standardized SSH version 2 through specifications published in January 2006. RFC 4251 defined the architecture, RFC 4252 covered user authentication, RFC 4253 the transport layer, and RFC 4254 the connection protocol. SSH-2 replaced weaker SSH-1 design elements with mechanisms including Diffie-Hellman key exchange and HMAC-based integrity protection.
The security improvements did not broaden SSH into a general network-access system. SSH authenticates a user or key to a host, then protects a defined set of sessions. An administrator can provide shell access, file transfer, database access, or a private web interface without automatically routing the user's other traffic through that server.
The design distinction is straightforward:
- SSH favors per-application access and minimal exposure.
- A VPN favors whole-network connectivity and convenience.
Neither approach is safer in every deployment. A restricted SSH tunnel may expose less than a broad VPN route, while a segmented VPN may be safer and easier to operate than numerous improvised forwards. The choice changes the potential blast radius. SSH makes narrow access easier; a VPN makes wider reach easier. Administrators must control the permissions, routes, forwarding rules, and reachable systems that each approach places within that boundary.
Application vs Network Layer Architecture
SSH and a conventional network-layer VPN don't merely use different configuration files. They carry traffic at different scopes.
SSH authenticates a user or key at a host and can forward selected TCP connections. If you use local port forwarding to reach an internal database, the database session travels through SSH, but unrelated browser traffic, operating-system updates, and other applications remain outside the tunnel. This narrow behavior is useful because the administrator can define access around a service instead of around an entire device.
IPsec takes a broader approach. NIST's guide to IPsec VPNs describes IPsec as a framework for private communications over IP networks, with requirements that include encryption, integrity protection, authentication, key exchange, logging, interoperability, and performance. An IPsec VPN can carry traffic from multiple applications without requiring those applications to understand SSH or use a special proxy configuration.
Layer Comparison
| Feature | SSH Tunnel | IPsec VPN |
| Operating scope | Primarily application-layer | Network-layer |
| Traffic selection | Specific forwarded connections | Broader IP traffic defined by routes and policy |
| Application changes | Often requires proxy, port, or tunnel configuration | Usually transparent to applications |
| Typical transport model | Encrypted client-server channels | IKEv2 negotiation and ESP-protected IP traffic |
| Best fit | One host, service, database, or administrative path | Subnet access, site-to-site connectivity, and many applications |
| Main control problem | Which destinations and ports can be forwarded | Which routes, subnets, and services the VPN exposes |
NIST also treats SSH as an application-layer alternative to IPsec in particular environments, not as a universal replacement for network-layer controls. That distinction prevents a common design mistake: building a collection of SSH forwards and assuming they behave like a routed network.
IPsec can use tunnel mode to encapsulate entire IP packets, or transport mode to protect the payload of direct IP connections. The practical result is transparent connectivity. Applications can use normal network behavior, including patterns that are awkward through SSH, such as broad service access, UDP-dependent tools, service discovery, and communication among multiple internal hosts.
Practical rule: Choose SSH when you can name the service you need. Choose a VPN when you need the network around that service.
SSH still has a meaningful advantage here. Its narrow scope supports least privilege without requiring a user to enter an entire private network. But that advantage disappears if administrators create permissive forwarding rules that reach large subnets. The protocol name doesn't decide the security boundary. The forwarding and routing policy does.
Performance Benchmarks and Overhead
Performance arguments in the SSH vs VPN debate often fail because they compare unlike tunnel designs. SSH port forwarding may carry one application connection, while a VPN encrypts and routes traffic from an entire device. A selective tunnel can avoid processing traffic that doesn't need private access, but a full VPN can handle broad workloads more naturally and may benefit from optimized packet processing.
A Swedish university thesis reported measurements of approximately 165 Mbit/s for IPsec and SSH port forwarding, 83.3 Mbit/s for OpenVPN, and 95.0 Mbit/s for an SSH-based VPN configuration. These results appear in the academic evaluation of SSH and VPN performance. They came from a particular test environment and implementation, so they shouldn't be treated as a permanent ranking.
The measurements still illustrate an important distinction. SSH port forwarding can be efficient when the application fits the tunnel, while an SSH VPN using a virtual network interface provides broader coverage but adds routing and configuration overhead. OpenVPN's result in that evaluation doesn't prove that OpenVPN is always slower than SSH or IPsec. Cipher selection, packet size, tunnel mode, hardware, and workload can change the result.
A newer controlled comparison
Another controlled test used identical Xeon E-2288G systems, 10-GbE interfaces, Ubuntu 24.04, and more than 300 runs. OpenSSH 9.8 with ChaCha20-Poly1305 reached 1.82 Gbit/s maximum throughput, 4.7 ms average latency, 124 ms connection setup, and 18.3% CPU utilization per 1 Gbit/s. WireGuard reached 3.95 Gbit/s, 2.1 ms, 11 ms, and 7.1%, respectively, according to the reported SSH and WireGuard benchmark.
That comparison favors a modern VPN for bulk, always-on, full-device, or site-to-site traffic. WireGuard's result shows why network-layer VPNs are attractive when the tunnel must carry sustained traffic efficiently. It doesn't mean that deploying a VPN will improve every SSH-based workflow, especially when the actual requirement is one database connection or one administrative interface.
What to measure before choosing
Nominal throughput isn't enough. Test the workload users will typically run:
- Application throughput: Measure file transfers, database queries, or the service that matters.
- Tail latency: Check interactive behavior under concurrent sessions, not only an idle tunnel.
- Connection setup: Include login and reconnect time for short-lived administrative operations.
- CPU saturation: Watch both endpoints while traffic and session counts increase.
- Failure recovery: Test how clients behave when the gateway, route, or connection disappears.
- Protocol fit: Account for MTU, packet size, TCP-over-TCP effects, congestion control, endpoint distance, and kernel-space versus user-space processing.
NIST recommends evaluating VPN connectivity, protection, authentication, compatibility, management, logging, performance, scalability, implementation security, and interoperability. The right benchmark is the one that reflects your users, applications, routes, and failure modes.
The Exposure Radius Fallacy
Security teams often ask whether SSH or a VPN is more secure, as if encryption alone determines the answer. The more useful question is how much private infrastructure becomes reachable after one identity, endpoint, or gateway is compromised.
An SSH deployment commonly publishes one service. That might be a shell, file transfer, or a forwarded connection to an internal application. A VPN can put a remote laptop inside a wider private network, where several hosts and services become reachable through normal IP routing. The second option is more convenient, but convenience can increase the blast radius.
Threat reporting treats both SSH and VPN services as valuable remote-access targets. A 2025 campaign reportedly used nearly 2.8 million source IP addresses against VPN and SSH services worldwide, as described in the ConnectWise 2025 MSP Threat Report. That figure doesn't tell an administrator which protocol to select, but it reinforces the need to protect whichever remote-access surface is exposed.
Least privilege versus network convenience
A compromised SSH account doesn't automatically provide access to every system that the host can route to. Its effective reach depends on shell permissions, forwarding policy, destination restrictions, firewall rules, and the services exposed through the account. That can produce a small, understandable security boundary.
A poorly segmented VPN may provide a much wider path. If the VPN identity can reach administrative interfaces, file shares, databases, and management systems across a routed network, one stolen credential can create opportunities for lateral movement. The VPN itself may be correctly encrypted while the network behind it remains too open.
The reverse failure also happens. Administrators sometimes assume that SSH is automatically narrow, then enable unrestricted forwarding or provide shell access to a bastion host with broad internal reach. An SSH tunnel can approximate VPN-like access. The decisive question is not whether the configuration uses SSH or a VPN. It's which destinations, ports, routes, and identities the configuration permits.
A sensible design uses separate controls:
- Identity controls: Require strong authentication, MFA where supported, or certificate-based identity.
- Host authorization: Restrict which source hosts and users may connect.
- Reachability controls: Limit forwarded destinations and VPN routes to the services required.
- Segmentation: Keep management systems separate from general application networks.
- Auditability: Log authentication, tunnel creation, forwarding activity, route changes, and administrative actions.
- Endpoint hygiene: Treat the remote laptop as part of the security boundary, especially when it carries other corporate VPNs or privileged credentials.
The following video provides a visual complement to the distinction between a narrowly scoped tunnel and broad network access.
The most defensible default is straightforward. Use SSH when one administrator needs one controlled path. Use a VPN when several applications require network-level connectivity, then restrict the resulting access so the convenience doesn't become an unbounded invitation into the network.
Network Exposure and Default Ports
The visible attack surface differs before authentication even begins. SSH servers normally listen on TCP port 22. A common IPsec VPN gateway may need UDP port 500 for IKE, UDP port 4500 for NAT traversal, and IP protocol 50 for ESP. CISA's communications infrastructure hardening guidance recommends minimizing exposure rather than opening services indiscriminately.
Port numbers don't determine security. They tell you what needs to be reachable, which is useful when writing firewall policy and reviewing an external attack surface. An SSH service may have one TCP entry point, while IPsec requires a small set of distinct protocols for negotiation and encrypted packet transport.
Reducing unnecessary visibility
Moving SSH from port 22 to another unused TCP port can reduce noise from automated scans, but it isn't an access control. CISA specifically recommends restricting SSH access to approved hosts instead of accepting connections from anywhere. A changed port without source restrictions, strong identity controls, and logging leaves the important security problem untouched.
For SSH, a practical exposure review should answer:
- Who can connect: Limit source hosts, users, and administrative groups.
- What they can do: Disable unnecessary shell capabilities and restrict forwarding destinations.
- Which service is reachable: Permit only the database, internal web application, or host required for the task.
- How access is recorded: Retain authentication and administrative activity logs for review.
- How access ends: Remove temporary rules and credentials when the work is complete.
VPN gateways need the same discipline, with additional attention to routes and tunnel policies. A user may authenticate successfully and still receive more network reach than the role requires. Route only the necessary subnets, separate administrative access from ordinary employee access, and apply firewall rules at the gateway and destination networks.
A VPN's larger traffic scope also creates an operational temptation. Once remote connectivity works, teams often add routes and exceptions to accommodate difficult applications. Each exception expands what the remote endpoint can reach. SSH usually makes the opposite trade-off by forcing the administrator to name a port or connection, although that constraint can become cumbersome when users need many services.
A different listening port can reduce background noise. It can't replace approved-host restrictions, robust authentication, segmentation, or a reviewable access policy.
The least-privilege position is therefore practical, not ideological. Keep SSH narrowly exposed for administration. Publish a VPN gateway when network access is necessary, but make its routes and firewall policy as specific as the business task allows.
Deployment Strategy and Recommendations
Start with the access requirement, not the protocol label. Write down the service, users, source devices, destinations, and traffic types involved. If the list contains one shell, one database, or one internal web application, SSH is usually the cleaner control. If it contains several applications across a private subnet, UDP-dependent software, service discovery, or site-to-site traffic, a VPN is usually the more natural fit.
A decision process that survives production
1. Define the smallest useful boundary.For administrative work, begin with a bastion host or directly authorized server and allow only the required SSH functions. Avoid granting broad forwarding just because it makes troubleshooting easier.
2. Select a VPN for a real network requirement.Use IPsec or another modern VPN technology when users need transparent access to multiple hosts and applications. Don't deploy a full-device tunnel merely to reach one management port.
3. Treat forwarding as routing.SSH port forwarding can create VPN-like reachability when it points into broad internal networks. Review every permitted destination and port as if you were reviewing a route table. A tunnel that reaches one service has a different risk profile from one that reaches an entire subnet.
4. Harden both paths.Pair either option with strong cryptography, MFA or certificate-based identity, host authorization, firewall rules, and audit logging. NIST's IPsec guidance emphasizes evaluation across security, management, interoperability, and performance rather than treating encryption as the only decision criterion.
5. Test the failure modes.Confirm that users can reconnect safely, that revoked identities stop working, and that a gateway or bastion outage doesn't force operators into an undocumented emergency path. Measure the application behavior that matters, including setup time, latency, CPU use, throughput, and recovery.
6. Recheck the boundary after deployment.List the services and subnets reachable from each role. Compare that list with the original task. If the route set has grown because of repeated exceptions, redesign the access model instead of accepting permanent sprawl.
For a small team, SSH may be enough for server administration, while a managed remote-access product can address devices that shouldn't accept inbound connections. NeoTeo has covered tools such as Psiphon, which supports VPN mode through L2TP over IPsec as well as SSH and SSH+ modes, and Dataplicity, a Raspberry Pi remote-access service that works similarly to a VPN without requiring SSH or an opened port. Those examples illustrate that remote access can be packaged in different ways, but administrators still need to inspect identity, reachability, logging, and dependency assumptions.
The best SSH vs VPN decision is rarely a permanent winner. It is a deliberately sized security boundary. Keep SSH focused on administration, use a VPN for genuine network connectivity, and review the reachable systems whenever the business requirement changes.
NeoTeo covers practical security, networking, software, and technology guides that can help you compare remote-access tools in real deployments. Visit NeoTeo to explore its tutorials and analysis before choosing the tunnel design you'll have to operate and defend.
