我的目标是在服务器公共 IP 的单个端口上建立 VPN 隧道，并能够使用额外的 VPN 加密层通过 SSH 进入服务器。
服务器配置的详细信息：
我在服务器和客户端上运行 CentOS 7。到目前为止，我读过的文档似乎都集中在通过浏览器运行并中继互联网流量的配置上。我不需要服务器中继任何东西。我可以通过 VPN 访问服务器的 SSH 端口，并将互联网流量 (80/443) 留在服务器和客户端上吗？服务器仍然必须能够通过 Apache 向公众提供 80/443，并且客户端可以正常访问互联网。
答案1
如果可以的话，我将冒昧地分解您的问题，退一步思考，并帮助您逐步完成整个解决方案设计过程，以便我们为您确定可行的解决方案。您的问题中关于 SSH 协议、VPN 以及一般而言我们如何设计安全系统存在许多不准确之处。让我们在这里解决它们。
目前，您的问题要求指导如何实施特定的技术。但是，您的问题陈述并未评估您面临的具体威胁，因此设计解决方案为时过早；在这方面，您XY 问题我们。
您实施的任何措施要么无法解决问题（因为问题实际上出在其他地方），要么会为本来就简单的解决方案增加复杂性。此外，不必要的复杂性也是不可取的，因为它可能会成为进一步的安全漏洞的根源。
严格定义你的问题
我们应该以目标为中心，不注重解决方案我们应该定义问题领域的对象，确定需要考虑的任何促成因素，了解我们面临的威胁，然后我们才能开始确定可以选择哪些技术和流程来解决手头的问题。我们可以遵循以下流程：
- 确定问题– 我们要解决的具体困难是什么？困难应该是一个客观的、可衡量的问题，并有实地观察得出的确实证据证明其存在。
- 确定假设和约束– 是否有特定项目可以假设处于特定状态，并且对所提出的解决方案还有其他条件？重大约束必须包括实施解决方案的直接成本（购买硬件、软件或咨询时间）和间接成本（进行流程变更、培训员工、适应生产力损失）。
识别威胁行为者（针对安全问题）-没有任何系统或流程是 100% 安全的。我们需要仔细确定所有可能发起攻击的对手的性质，以确定我们的解决方案是否足以防止此类攻击。这既适用于设计现实世界的物理安全系统，也适用于设计技术成果。
例如，在您的评估中，您可以考虑以下因素：
- 对手的能力– 他们的知识水平如何，是否可以使用特定资源来协助攻击，等等。
- 他们的立场– 住宅互联网服务最后一英里的脚本小子与能够访问网络中可进行中间人攻击位置的国家行为者之间存在很大差异
你的风险和风险恒温器– 攻击者攻击您或您的组织的动机是什么？例如，您的系统是否存储或处理敏感和/或特权数据，这些数据通常属于受限制性质，但可能对其他人有价值（个人数据、公司机密等）？它是否在网络中具有特权位置，可以从中发起进一步的分析或攻击（例如 ISP 中的核心路由器、大型公司敏感网络周边的边界网关）？
这有助于确定我们是否正在应对试图针对你具体来说，或者我们是否在防守机会主义者。通过采取适度的保护措施来防御路过的机会主义者会容易得多，这会让你看起来比竞争对手更安全。
此外，确定你的风险偏好（你的风险恒温器) 有助于优化结果，以适当覆盖已识别的风险，而不会显得过分。
- 实施决策– 利用从这一过程中收集的信息，考虑到所描述的限制和我们对风险的立场，确定合适的技术和流程改变以解决问题，如果无法找到解决方案，则修改约束或风险状况。
在整个过程中，我们记住安全是一个过程，而不是目的我们不能“购买”现成的安全商品，任何提出这种观点的人要么在撒谎，要么有不可告人的（很可能是牟取经济利益）动机。
你的具体问题
您的问题非常全面，因此我们可以按照我们的流程来解决您的具体问题：
问题
根据 rkhunter 分析，我经历过一次服务器入侵，并想降低这种情况再次发生的可能性。
该具体问题是机器过去受到的损害，您希望尽量减少其再次发生。
从您的问题中我可以看出，主要目标是加强计算机对可能通过公共网络（如互联网）发生的远程入侵事件的防御。次要目标是确保远程计算机的远程 shell 会话的机密性和完整性。
假设和约束
让我们记录这些要点来指导我们的解决方案：
- 从机器公开的公共网站服务是安全的
- 您发起远程连接的工作站不是攻击相关服务器的代理。例如，它们本身不会被渗透（因此它们不是密钥泄露或被修改的载体，也不是用于建立连接的二进制文件被篡改的载体）。您可能希望单独探索任何客户端计算机的安全漏洞，或将它们纳入单个评估中。
- 服务器计算机在物理上是安全的，由亲自访问该计算机的人员篡改硬件或软件配置的可能性不大或可能性不大。（攻击者可以物理访问的计算机不太可能再是您的计算机。）
- 网络可能已被攻陷。可能有人有能力拦截或转移我们的数据包。
- 我们希望使用免费软件来实现我们解决方案的技术方面。
- 我们假设用户经过充分培训，因此可以忽略对湿件（人类操作员）的攻击（例如社会工程威胁）。同样，原则上，这些攻击很少得到充分缓解，并且对大多数组织来说都是一个弱点，但这是服务器故障，所以除了顺便提一下之外，我将忽略攻击模型的非技术方面。
- 如果解决方案需要在第一次连接之前离线分发或验证密钥，这是可以接受的。
- 众所周知的加密原语被认为不受后门或未公开披露的攻击。
威胁模型
我无法充分确定您的威胁模型，因为我无法了解您的组织和基础设施，也无法概览您处理的数据组合或您可能内部连接的私人网络。从您个人资料中的公开信息来看，我可以看到您可能在代表他人处理敏感知识产权的地点工作，这将构成特定攻击威胁的中高风险数据收集。（此威胁可能会扩展到您操作的个人系统。）
执行
让我们设计一个符合我们目标的解决方案。为了强化机器，我们需要考虑公共攻击路线。它公开了两个服务，我们假设 Web 服务不易受到攻击。因此，我们必须考虑远程 shell 连接。
以此目的，SSH 功能强大无需添加 VPN 会话包装即可满足您的要求。几乎任何 Unix 机器都能够运行 SSH 守护进程，并且相当一部分机器直接或间接地暴露在敌对网络中而不会被渗透。
SSH 如何满足我们的目标？
安全 Shell (SSH) 旨在提供远程 Shell 会话的机密性和完整性。它使用加密方法来实现这一点；具体来说，主机被分配一个或多个主机密钥，可用于向连接的客户端计算机准确识别主机。
SSH 的中间人攻击
正如您正确指出的那样，SSH 在特定情况下容易受到中间人攻击：大多数用户不会在初始连接时检查机器提供的主机密钥；他们部署一个首次使用即可获得信任策略。如果中间人此时可以提供替代主机密钥，则现在和将来的连接中无需进一步检测即可拦截 SSH 会话。在不检查缓存主机密钥的情况下进行检测需要消除中间人威胁，或者从未受攻击的网络进行连接，以便可以显示远程主机的真正主机密钥。
由于我们担心中间人攻击，因此我们必须设计一个解决方案来缓解这种情况。可供您使用的选项包括（非详尽）：
- 仅通过受信任网络连接。这是行不通的，因为它不符合我们关于通过公共网络连接的目标或假设。
- 在初始连接之前分发主机密钥的指纹（或其整个公钥）。使用
ssh-keygen服务器上的命令获取指纹，将其分发给用户，并让他们将首次连接时显示的指纹与服务器上的版本进行比较。只有指纹匹配时，他们才必须登录。 - 在 DNS 中发布主机密钥并使用 DNSSEC 对区域进行签名。确保所有连接的客户端都使用 DNSSEC 验证解析器并验证基于 DNS 的主机密钥。更多信息请点击此处这种方法避免了分发和手动验证主机密钥的负担，但需要特定的技术组件，而这些组件在许多网络上尚未普及。
暴力密码攻击
正在运行的 SSH 守护程序的另一个漏洞是暴力密码攻击。攻击者通常会探测您的机器是否有 SSH 服务，并尝试使用常用的用户名和密码列表进行身份验证。用户名在公共列表中且密码较弱的机器很可能受到攻击。缓解这种情况的方法包括：
- 将 SSH 守护程序切换为使用基于密钥的身份验证，并禁用来自公共互联网的密码身份验证。使用
ssh-keygen较大的位数（例如 >2048）为您的用户帐户生成 RSA 密钥对，或使用其他加密系统签名的密钥对的适当位数生成 RSA 密钥对。 - 使用软件
fail2ban来监视您的日志并添加防火墙规则，以在达到失败登录阈值后阻止来自同一地址的进一步连接尝试。
VPN 有帮助吗？
VPN 解决方案可能解决的问题与您使用 SSH 隧道所要解决的问题相同。它们可能使用不同的技术方法或不同的加密系统，但两者都足以履行您的安全义务。两者也会产生类似的开销（例如，预先向各方预分发或验证密钥的义务是相同的）。
如果您只想操作远程 shell 服务器，VPN 提供的附加功能在这种特定情况下似乎是不必要的。运行 VPN 可能会带来额外的风险，因为其他在您的机器上运行的守护进程和更大的攻击媒介。