云主机怎么开跳板机，搭建前先看这几个坑

很多团队买了云主机后，都会冒出一个很实际的想法：能不能顺手拿来做跳板机。这个思路没问题。开发、运维、测试需要统一入口访问内网服务器时，用云主机做跳板机，确实能把权限、审计和访问路径收拢起来。问题在于云主机怎么开跳板机，以及开起来之后会不会留下新风险。

跳板机到底解决什么问题

跳板机就是放在外部访问者和内网主机之间的一台中间服务器。运维人员先登录这台机器，再由它去访问业务机、数据库机或测试机。这样做的效果很直接：入口集中，权限更好收，排查时也更容易回头查人和时间。

• 入口统一：不需要每个人直接连所有服务器。
• 方便审计：谁在什么时间登录了哪台机器，更容易留痕。
• 权限隔离：可以按用户、密钥、白名单控制访问范围。
• 减少暴露面：内网主机不必直接开放公网端口。

所以，问云主机怎么开跳板机，不能只盯着装个 SSH 服务。入口怎么收、谁能进、进来后能做什么、日志放哪，这几件事要一起看。

什么情况下适合用云主机做跳板机

不是所有环境都要上重型堡垒机。中小团队、项目初期、临时环境，或者只是想先把访问入口管起来，一台配置合适的云主机通常就够用。

比较常见的场景

• 开发和测试环境里有多台 Linux 主机，团队需要集中登录，不想每台都单独暴露公网。
• 成员分散在不同地区，需要通过公网访问内网资源，但又不希望业务机直接对外开放。
• 数据库、缓存、业务机都想收口到一个入口，方便做账号和权限管理。
• 暂时没有采购专业堡垒机，但已经意识到共享账号、全网开放 SSH 这种做法风险太高。

如果团队规模很大，合规要求严格，或者已经明确需要会话回放、命令审批、细粒度授权，轻量跳板机就不太够了。这类场景还是要考虑专业堡垒机。云主机跳板机更适合先把基本访问入口管住的阶段。

云主机怎么开跳板机，先把结构想清楚

动手之前，先确认几件事，不然后面很容易返工。

1. 跳板机有没有公网 IP，公网访问范围准备怎么收，是全网开放，还是只允许固定出口 IP。
2. 目标服务器是否只接受来自跳板机内网 IP 的访问。如果业务机还对公网开着 SSH，跳板机的意义会打折扣。
3. 团队成员准备用账号密码还是 SSH 密钥登录。如果是长期使用，最好一开始就按密钥和个人账号设计。
4. 要不要留登录日志、sudo 操作记录、命令历史，日志是只留本机，还是同步到外部。
5. 这是临时方案，还是未来会长期承担运维入口角色。临时和长期，对账号管理、补丁、审计的要求不一样。

比较稳妥的结构是公网只开放跳板机，业务主机只允许跳板机从内网访问。这样外部访问路径是单点，内网主机不直接暴露在公网，风险会小很多。

搭建步骤：从 0 到 1 做出一台可用跳板机

1. 先选一台维护方便的云主机

跳板机不一定要很高配置。多数场景下，基础型云主机就能承担这个角色。比起 CPU 和内存，网络稳定、安全组规则是否清晰、系统后续维护是否方便，影响更大。系统方面，CentOS、Rocky Linux、Ubuntu 都可以，优先选团队熟悉、后续补丁和账号管理顺手的版本。

2. 端口别开多，安全组先收紧

跳板机最常见的入口是 SSH，因此通常只需要开放 SSH 端口。很多人会把默认 22 改成自定义端口，这能减少一部分扫描噪音，但别把它当成主要防护手段，真正有用的还是访问源限制。

• 安全组尽量只放行公司出口 IP 或管理员固定 IP，不要图省事直接对全网开放。
• 系统里不需要的服务和端口关掉，避免一台入口机上还挂着一堆无关组件。
• 如果现有环境能先走 VPN，再访问跳板机，这比直接把 SSH 暴露在公网更稳。

这里有个常见误区：业务机安全组限制得很严，跳板机却对所有公网开放密码登录。结果跳板机先成了被盯上的目标。入口机要比普通业务机更严格。

3. 不要共享 root，给每个人单独账号

很多团队前期为了省事，大家都直接用 root，或者共用一个 ops 账号。短期看是方便，出问题时最麻烦。你只能看到“有人动过”，很难知道是谁动的。

更合适的做法是一人一号，再根据职责授予 sudo 权限。开发登录测试机和应用机，运维负责生产环境，数据库权限单独管。这样做也方便后续增删权限，人员入职、离职、岗位调整时，不用整套密码一起改。

4. 登录方式优先用 SSH 密钥

回答云主机怎么开跳板机这个问题时，密码登录当然能用，但不该作为主要方案。长期使用的跳板机，建议直接以 SSH 公私钥认证为主，同时把几项基础限制配上：

• 禁用 root 直接远程登录，避免高权限入口过于直接。
• 关闭弱密码和空密码，别给暴力尝试留机会。
• 定期轮换密钥，人员离职时及时清理账号和公钥。

如果团队已经有固定设备和办公网络，再叠加登录白名单，会比单纯改端口更实在。

5. 让跳板机只通向该去的机器

跳板机搭好后，还要处理它到目标主机的访问关系。通常做法是把跳板机的公钥分发到目标主机，并在目标主机安全组或防火墙里，只允许来自跳板机内网 IP 的 SSH 连接。数据库服务器也一样，谁该连、谁不该连，规则写清楚。

做到这一步，云主机怎么开跳板机的基础功能就成型了：外部用户先登录云主机，再从云主机进入内网机器，业务机本身不直接对外开放管理入口。

6. 轻量方案也要把日志留住

没有专业堡垒机，不代表可以没有审计。至少要把基础日志保住：

• 系统登录日志要保存，能回查谁在什么时间进过跳板机。
• sudo 操作要有记录，方便排查提权和关键变更。
• Shell 历史命令可以作为辅助线索，但别把它当成完整审计。
• 日志尽量同步到独立存储或日志平台，不要只放在本机。

这里要提醒一句：history 只是基础线索，不是强审计。熟悉 Linux 的人有办法规避或清理。如果环境对审计要求高，就要上更专业的会话记录方案。

一个很典型的使用场景

有些小型 SaaS 团队一开始服务器不多，比如 2 台 Web、2 台应用、1 台 MySQL、1 台测试机。前期为了快，6 台机器都开着公网 SSH，开发和运维各自保存账号密码。平时看起来没事，直到日志里开始频繁出现异常扫描，大家才意识到入口太散。

这种情况下，调整方式通常不复杂：新开 1 台云主机作为统一跳板机，只保留这台机器的公网 SSH 入口；其他服务器关闭公网登录，只保留内网访问；团队成员改成个人账号加 SSH 密钥；数据库服务器只允许应用机和跳板机访问。

改完之后，变化会很明显：

• 公网暴露面从多台缩到一台，扫描和暴力尝试集中在一个入口上，便于防护和观察。
• 成员权限边界更清楚，出了问题更容易回溯访问路径。
• 新人入职、老员工离职时，只需要处理个人账号和密钥，不用担心共享密码四处散落。

这也是很多团队真正在意的点：能不能用较小改造成本，把原来分散、混乱的访问方式收回来。只要结构设计对，轻量跳板机已经能解决不少实际问题。

搭建时最容易踩的几个坑

只把路打通，没做权限分层

有些团队把跳板机搭完，就默认所有人都能进所有目标主机。这样只是把入口集中，风险并没有收住。更合理的做法是按角色分组：开发只进开发和测试环境，运维负责生产，数据库权限单独控制。权限一开始分清楚，后面省事得多。

跳板机自己成了薄弱点

跳板机如果对全网开放、允许密码爆破、补丁长期不打，它往往会先被盯上。别把它当普通云主机看待，它是管理入口，一旦失守，后面的内网主机也会跟着暴露。

日志全留本机

日志只保存在跳板机本地，机器一旦损坏、被入侵或者被恶意清理，线索就没了。更稳妥的做法是把认证日志、操作日志同步到外部系统，至少别把所有证据都压在一台机器上。

共享账号一直拖着不改

“现在人少，先共用 ops 账号”是很常见的说法，但这种临时方案通常会拖很久。等服务器变多、成员变多，再拆共享账号，成本会更高。能一开始就一人一号，就别留这个尾巴。

想做得更稳，可以继续补这些能力

把“云主机怎么开跳板机”这个基础问题解决后，如果准备长期使用，可以继续往生产入口的标准靠：

• 双因素认证：给 SSH 登录增加动态验证码，降低密钥泄露后的风险。
• 登录白名单：只允许办公网或 VPN 出口访问，减少无关流量接触入口。
• 命令审计：加强会话记录和操作追踪，满足更高的排查要求。
• 自动化配置：用脚本或配置管理工具统一发放账号和密钥，避免人工漏配、错配。
• 定期巡检：检查异常账号、异常端口、补丁状态和无效密钥，别让入口机长期失管。

以后业务复杂了，再从这台轻量跳板机升级到成熟堡垒机，迁移也会顺一些。因为访问路径、权限分层、账号习惯已经先立住了。

云主机开跳板机，先把关键动作做扎实

回到开头的问题，云主机怎么开跳板机？思路可以压缩成一句话：选一台安全可控的云主机做统一入口，用 SSH 密钥、最小权限、安全组和日志留痕，把访问内网服务器的路径收拢起来。

对多数团队来说，先做好几件事就够了：只留一个公网入口，业务机尽量不暴露外网，一人一号，密钥登录，日志别只存本机。这套做完，一台轻量跳板机已经能承担起大部分基础运维入口的工作。后面再补命令审计、双因素认证或者更细的权限设计，会比一开始追求大而全更稳。