为什么个人站长也需要一台堡垒机
很多个人站长手里只有一两台 VPS，觉得堡垒机（跳板机）是大公司才用的东西，自己直接 SSH 上去就够了。但只要你的服务器数量超过三台，或者你把服务器借给朋友、同事、合作者用过，运维入口的安全审计问题就会立刻暴露出来：谁在什么时候登录了哪台机器、执行了什么命令、有没有偷偷拷走数据库，这些你一概不知道。更麻烦的是，一旦某个人的电脑中招，他本地保存的私钥就等于把所有服务器的钥匙一起交了出去。
堡垒机要解决的核心问题其实就三件事。第一是统一入口，所有运维人员不再直连业务服务器，而是先登录堡垒机，再从堡垒机跳到目标机器，业务机只信任堡垒机一个来源 IP。第二是权限收口，谁只能看哪几台、能不能执行 sudo、能不能传文件、能不能开数据库客户端，全部在堡垒机上集中定义，不用去每台机器上改 sshd_config 和 authorized_keys。第三也是最重要的一件，操作审计，完整的会话录像加上命令记录，出事后能倒查。
本文以开源堡垒机 JumpServer 为例，讲清楚在个人 VPS 上从零搭一套能用的堡垒机的全流程，包括架构选型、资产纳管、权限模型、会话录像原理，以及几个我实际踩过的坑。
JumpServer 的四个组件与部署方式取舍
JumpServer 采用典型的四组件分离架构，理解这四块各自负责什么，是后续排错的基础：
- Core（jumpserver）：主服务，负责 Web 界面、认证、权限判定、会话调度，是整个系统的大脑。
- Koko：用 Go 写的 SSH/SFTP/RDP 协议代理网关。你 SSH 到堡垒机的 2222 端口，实际连的是 Koko，由它再去连目标资产，同时把字符流录下来。
- Lion：Web Terminal 网关，负责浏览器里直接打开一个终端窗口，以及 RDP/VNC 图形会话的代理。
- MySQL + Redis：MySQL 存资产、用户、权限这些元数据，Redis 存会话状态和缓存。
部署方式上，官方提供了几种选择。最简单的是 一键安装脚本（install.sh），它会用 Docker Compose 把全套组件拉起来，适合单机快速验证。第二种是 Docker Compose 手动编排，适合你想控制每个组件的资源、版本和网络。第三种是 Kubernetes Helm Chart，这已经超出个人站长的需求范围了。
对个人站长来说，我推荐用一键脚本先把环境跑通，理解界面和权限模型之后，再考虑用 Compose 手动编排做生产化改造。一键脚本会额外装一个 Caddy 或 Nginx 做前端反代，需要注意它默认会申请 Let's Encrypt 证书，如果你的域名没有提前解析好，脚本会卡在证书申请那一步。
单机部署实操与端口规划
假设是一台 4 核 8G 的 VPS，操作系统 Debian 12。先做基础准备：
apt update && apt install -y curl wget git
# 安装 Docker 与 Compose 插件（官方源，别用系统自带的旧版本）
curl -fsSL https://get.docker.com | bash
docker --version
# 关闭 swap 上的随机化（JumpServer 的 MySQL 对内存较敏感，建议加 swap 分区）
fallocate -l 4G /swapfile && chmod 600 /swapfile
mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab然后下载一键安装脚本。注意官方仓库地址经常调整，一定要去官网文档拿最新的地址，不要照抄老博客里的链接：
cd /opt
git clone --depth=1 https://github.com/jumpserver/installer.git
cd installer
# 交互式安装，会依次问：安装目录、镜像加速、是否自动生成随机密钥、数据库密码
./jmsctl.sh install安装完成后，几个关键端口要记住：
80 / 443：Web 界面（前端反代）2222：Koko 的 SSH 入口，运维人员从这里 SSH 进来3306 / 6379：MySQL 与 Redis，默认绑 127.0.0.1，绝对不要放开到公网
首次访问 Web 界面，默认账号是 admin，初始密码需要执行 ./jmsctl.sh showkey 或查看安装日志获取。登录后第一件事就是改掉默认密码并配置双因素认证，堡垒机是整个基础设施的入口，它失守等于全盘失守。
资产纳管：把服务器、数据库、应用都登记进来
JumpServer 把所有可运维对象统一抽象为「资产」，分为主机、数据库、应用、云服务等类别。个人站长最常用的是主机和数据库两类。
纳管一台 Linux 主机，需要先在目标服务器上创建一个专用的运维账号，例如 ops，并配置好 sudo 规则。然后在 JumpServer 的「资产管理 → 资产列表」里新建资产，填写 IP、SSH 端口、账号。更规范的做法是使用「系统用户」概念：你在 JumpServer 里定义一个系统用户（比如 ops），配置它的密码或密钥，JumpServer 会自动把这个用户推送到目标主机上。这样你的私钥只存在堡垒机里，运维人员的电脑上不落地任何密钥。
纳管数据库同理。JumpServer 支持 MySQL、PostgreSQL、Redis、MongoDB 等，你填好连接信息后，运维人员不需要知道数据库真实密码，直接在网页上点开就能用内置的 SQL 客户端连接，连不连接、能不能导出、能不能执行 DDL，都在权限里控制。
一个容易被忽略的细节：资产纳管时强烈建议给每台资产打上标签（Label），比如「生产」「测试」「华东」「数据库」。后面配权限时，你可以直接按标签批量授权，而不用一台台勾选。资产一多，标签就是救命的东西。
权限模型：用户 → 用户组 → 资产 → 系统用户
JumpServer 的权限逻辑是这条主线：用户（登录的人）属于用户组，用户组和资产之间通过「资产授权」关联，授权时指定用哪个系统用户去连。理清这条线，就不会配错。
举个例子。「授权规则」里填：用户组 = 运维组，资产 = 生产服务器（标签），系统用户 = ops，动作 = 全部，有效期 = 永久。这条规则的意思是：运维组里所有人，可以用 ops 账号登录所有带「生产」标签的机器。
实际作权限设计时，我建议遵守最小权限和分环境两个原则：
- 测试环境和生产环境分开授权，不要把两台混在一个规则里，否则未来想收权时会很痛苦。
- 只读账号与可写账号分开。给需要查看日志的同事配一个只能看不能 sudo 的账号，别图省事直接给 root。
- 文件上传下载单独控制。JumpServer 可以禁止某个系统用户传文件，这对防止数据外泄非常关键。
会话录像：字符流录制与回放原理
会话录像可以说是堡垒机存在的最大理由。它的原理并不神秘：运维人员 SSH 到 Koko 的 2222 端口，Koko 与目标主机建立第二条 SSH 连接，然后在两端之间做「中间人」转发——键盘输入从 Koko 转发到目标主机，目标主机的输出从 Koko 转发回运维人员。在转发的同时，Koko 把整个输入输出流按时间戳记录成录像文件。
回放时，它不是视频，而是按录制时的时间轴重新把字符流播放一遍，所以文件极小、可以暂停、可以复制文本，比录屏强得多。你可以在「会话管理 → 会话记录」里看到所有历史会话，点击就能在线回放，也能下载下来。
有几个实用的审计要点：
- 命令记录：除了录像，JumpServer 还会单独抽出一份「命令记录」，可以按关键词搜索，比如搜
rm -rf、mysqldump，快速定位高危操作。 - 录像存储：默认存在本地磁盘，长期运行会撑爆磁盘。务必配置对象存储（S3 / MinIO / 阿里云 OSS）或定期转存并清理。
- 会话中断：管理员可以在告警页面一键踢掉正在进行的会话，比如发现有人在生产库上执行危险 SQL。
四个我实际踩过的坑
坑一：只纳管了资产，却忘了给运维人员开 2222 的访问
很多新手装完堡垒机，Web 界面能登录，资产也建好了，结果运维人员 SSH 2222 连不上。原因通常是云厂商的安全组没放行 2222 端口，或者服务器本机的 firewalld / ufw 拦掉了。务必确认 2222 对运维人员的来源 IP 开放。生产环境更稳的做法是把 2222 只对办公网 IP 开放，而不是 0.0.0.0。
坑二：数据库和 Redis 被暴露到公网
一键脚本在某些网络环境检测失败时，会把 MySQL 的 3306 绑到 0.0.0.0，导致数据库直接暴露。装完之后一定要执行 ss -lntp 检查所有监听端口，确认 3306、6379 只绑 127.0.0.1。我就遇到过一台测试机被扫描器扫到裸露的 Redis，虽然只存放会话缓存，但隐患极大。
坑三：录像把磁盘写满
一个活跃的运维会话，录像文件可能几 MB，日积月累非常可观。如果 VPS 只有 40G 磁盘，跑几个月就会告警。解决办法是配置外部对象存储，或者在 /opt/jumpserver 下挂一块独立的数据盘专门放录像，再配一个定时任务清理超过 180 天的旧录像。
坑四：以为装了堡垒机就安全了
这是认知层面的坑。堡垒机的价值在于「统一入口 + 审计」，但它自己也是一台服务器，如果它的默认密码没改、SSH 还开着 22 端口直连、版本长期不升级存在漏洞，那它就是新的短板。装完记得：改默认密码、开 2FA、把 JumpServer 自己的 22 端口限制来源、定期升级版本。
总结：个人站长的堡垒机该怎么落地
堡垒机不是大厂专属，个人站长用开源方案完全能搭。我的建议是分三步走。第一步，先用一键脚本在测试环境跑通整个流程，理解资产、系统用户、授权、会话这几个核心概念。第二步，把生产服务器的 SSH 直连逐步关掉，改为只允许堡垒机的 IP 访问 22 端口，让所有运维入口收口到堡垒机。第三步，配置录像的异地存储和定期清理策略，把审计数据当成一项需要长期维护的资产来对待。
真正上线之后你会发现，堡垒机带来的安全感是实打实的：再也不用担心「同事离职后还留着所有服务器私钥」，也不用担心半夜出故障时翻不出是哪次变更导致的。对任何认真对待自己服务器的站长来说，这一步投入的时间，回报是长期且确定的。