VPN 和 SSH 在某种意义上是相似的，它们都建立了一个受信任和加密的点对点通道，但相似之处几乎就在于此。VPN 的目标是授予您对否则无法访问的网络的访问权限，而 SSH 的目标是授予您对特定系统的 shell 访问权限。它们扮演着不同的、非排他性的角色——在能够使用 SSH 之前需要 VPN 是非常常见的。

通过直接 ssh 使用 VPN 有很多好处。SSH 是一个根级别的守护进程，可以直接访问设备。过去 SSH 中存在 0-day 漏洞，谁知道呢，可能会有一个潜伏在拐角处，使攻击者可以直接访问任何暴露在互联网上的系统。或者，配置错误的 ssh 守护程序可能允许使用可以通过击键猜测或嗅探的密码登录。不将您设备上的 ssh 直接暴露给互联网是一个非常好的安全策略。

另一方面，VPN 通常是通过设备或非 root 守护程序完成的，从而限制了攻击面。VPN 还极大地简化了对受限资源的访问，而不仅仅是 SSH——例如仅限内部的网站。虽然您可以使用 SSH 进行端口转发，但与使用 VPN 相比要麻烦得多。此外，运行 VPN 服务器允许实现集中式 2 因素身份验证、将静态内部 IP 地址分配给经过身份验证的帐户等。后者在通过 netflow 跟踪管理员访问以及按组限制对内部资源的访问时非常有用。

换句话说，在系统上访问 ssh 之前需要 VPN 连接既是常见做法，也是良好的安全策略。

其中很多将归结为您的实际需求和个人选择。

可以通过 SSH 传输大量流量并将其视为 VPN。

两者之间也有许多相似之处，例如，根据您选择的 VPN 选择，您可能还为 VPN 使用 SSL/TLS，这是 SSH 使用的，甚至是相同的密码、算法或加密库。因此，尽管加密选项存在一些差异，但加密选项非常相似。

它们开始不同的领域涉及您是否需要第 2 层流量（例如以太网帧）与仅具有 IP 流量（大多数人需要）。或者，如果您想通过同一连接永久转发多个协议或用户，在这种情况下，VPN 可能更容易。

某些 VPN（并非全部）的一个缺点是，如果您从远程位置连接到它们，您可能会发现某些协议（例如 IPSEC）可能被某些提供商阻止。

一般来说，我发现如果您只是建立单一连接，无论您是手动执行此操作还是通过脚本执行此操作，SSH 都将更容易管理。

如果您有一个包含许多未加密协议的更复杂的网络，您可以选择使用 VPN 路由。

两者都是很好的解决方案，如果有的话，我建议您尝试一下，看看哪一个最适合您的需求。

就我个人而言，我倾向于将 SSH 作为我的首选工具，因为它非常灵活，但我偶尔会推荐 VPN 用于更大的站点到站点连接或 100% Windows 商店的客户端。

在高安全性环境中，我使用两者并通过 VPN 运行所有 SSH 连接。您可能也想尝试一下。

归根结底，由于 SSH 的灵活性，两者非常相似，很多决定将取决于您的个人偏好和需求。

我会非常担心认为 SSH 和 VPN 术语适用于相同功能的安全“专家”。我认为这个故事在重述中丢失了一些东西。

VPN 只是意味着加密的网络连接。有多种技术可以做到这一点；TLS、PPTP 甚至 SSH 等等。假设您正在专门谈论 TLS VPN....

TLS 和 SSH 有非常不同的信任模型。对于 SSH，在客户端和服务器之间建立信任。使用 TLS，客户端和服务器都信任证书颁发机构。后者提供了一些集中控制，但以更大的攻击面为代价。

撇开信任的概念模型不谈，看看 SSH 与 TLS 相比的漏洞历史，SSH 公开的安全缺陷比 TLS 少也就不足为奇了——它是一个更简单的协议。

恕我直言，试图在网络中添加安全性的概念从根本上是有缺陷的——网络上的每个节点都应该是安全的，并且所有连接都应该在端点进行身份验证（中间的防火墙只能帮助减少噪音）。因此，我的建议是为应用程序使用适当的技术；SSH 用于 shell 和 Xwindow 访问，TLS 用于 HTTP、SMTP 和 IMAP。但是对于基于 UDP 的协议或需要低延迟的 TCP 连接，IPSEC 是传统 SSL/SSH 隧道的一个很好的替代方案。

在某些领域，该技术不明确支持其中一个或另一个（例如许多数据库服务器），而在某些领域，它已深深融入协议（例如 FTPS 与 SFTP），但应该逐个协议地考虑这一点。