告别传统探针：Mosona Manager 深度体验 —— 个人自用轻量堡垒机与监控新选择

在MJJ圈子里，大家最常用的探针莫过于哪吒监控（Nezha）、Komari 或者经典的 ServerStatus。不少朋友把几十台吃灰小鸡挂在网页上，看三网延迟、看在线绿灯，其乐融融。

Mosona Manager（作者在 NodeSeek 发布了官方介绍贴），虽然提供了一个高颜值的公开状态展示页，但如果你仔细研究它的底层设计，就会发现它根本不是传统意义上的“小鸡探针”，而更像是一个面向个人或极小团队自用的轻量级 JumpServer（堡垒机）兼服务器监控面板。

更重要的是，针对近两年来传统探针频发的安全漏洞与被滥用为黑客后门的乱象，Mosona Manager 给出了完全不同的解题思路。

NOTE
自建公开探针预览页已上线，可以直接访问 agent.catcat.blog/preview/status 体验实际展示效果。

Mosona Manager 官方主界面预览

个人自用的轻量 JumpServer#

市面上已经有了成熟的企业级堡垒机 JumpServer，但对于绝大多数玩家来说，官方 JumpServer 过于庞大沉重——动辄数个微服务、4C 8G 的内存开销、复杂的资产审批流和庞大的配置，个人用起来就像“开航母去钓鱼”。

Mosona Manager 的定位非常务实，绝非什么高大上的企业级系统，而是一个专为个人/小规模自用打造的轻量堡垒机替代品：

解决痛点：手里有几台或十几台 VPS，不想在本地 SSH 工具（如 Termius、FinalShell、SSH Config）中到处同步私钥，想随时在浏览器里点开 Web 终端快速敲几句命令，顺带查查服务器的各项运行负载。
轻量团队/多项目划分：支持创建 Team，给几个朋友或协作者分配只读监控查看权，或者单独控制是否开放 Web SSH 终端权限。
操作日志与审计：记录登录时间、来源 IP 和终端会话行为，具备基本的运维审计底线。

避坑提醒：两点必须明确的硬性限制#

在考虑部署之前，有两件事必须首先想清楚，否则一定会失望：

1. 没有延迟监测功能#

传统探针的核心灵魂是 Ping/TCP 延迟监控矩阵，很多玩家靠它观察各机房的回国路由波动。Mosona Manager 完全没有这些网络延迟监测与打榜功能。

它监控的是操作系统内部的健康指标（CPU、内存、磁盘 IO、系统负载、网络实时吞吐等）。如果你是为了看三网测速或延迟曲线，它不适合你。

2. InfluxDB 是吃内存怪兽，不要低配小鸡部署#

不同于传统探针只用 SQLite 或单个轻量二进制，Mosona Manager 为了实现秒级/分钟级的精准指标追溯，引入了 InfluxDB 2 作为专业时序数据库（搭配 PostgreSQL 18、Redis 7 与 Go Hub 主控）。

高精度时序数据库的代价是真金白银的硬件开销：

严禁在 1 核 512MB / 1GB 内存的低配小鸡上运行主控！极易遭遇 OOM（内存溢出）甚至直接把小鸡卡死。
推荐配置：主控机宿主机建议至少拥有 2 核 CPU、2GB 内存（推荐 4GB）。如果手头只有廉价小玩具机器，请不要轻易尝试自建主控。

为什么传统探针让人不安心？谈谈哪吒与 Komari 的安全隐患#

聊到服务器监控，很多老玩家近几年都在经历“从狂热追捧到逐渐卸载”的过程。究其原因，正是传统探针在架构设计上带来的严重安全隐患。

1. 侵入式常驻 Agent 的“高权限原罪”#

为了实现所谓的一键下发命令、在线文件管理、网页 Web Shell，哪吒探针和 Komari 等工具通常要求在被控机以 root 或高权限常驻一个后台 Agent 守护进程。

这意味着，你在自己名下几十台 VPS 上，亲手为外部面板开辟了一条拥有最高权限的远程执行管道（RCE）。一旦主控端有任何失误，所有节点瞬间集体沦陷（俗称“一锅端”）。

2. 被黑客当成现成 C2 后门滥用（Living-off-the-Land）#

由于这类探针功能过于强大、且本身属于合法开源软件，知名安全厂商（如 Huntress 等）曾多次披露安全报告：黑客在通过其他漏洞入侵服务器后，会主动在受害机器上部署哪吒或 Komari 的 Agent 作为持久化后门与 C2 控制通道。

黑客利用合法运维软件的隐蔽性来逃避杀毒扫描与告警，而很多运维人员甚至分不清跑在机器上的 Agent 到底是自己装的还是黑客装的。

3. 历史高危 CVE 频发#

仅在过去一段时期内，传统探针就被披露了多个 CVSS 评分极高的严重漏洞：

CVE-2026-53519（高危路径穿越漏洞，CVSS 9.1）：攻击者无需任何认证即可读取主控服务器文件（如 config.yaml），从而直接窃取 JWT 密钥和 Agent 通信令牌，完全接管后台。
CVE-2026-62283（严重跨租户隔离漏洞，CVSS 9.9）：允许攻击者绕过权限边界，直接跨租户进入他人机器的终端或文件管理器执行任意 Shell 命令。
CVE-2026-46716（RCE 远程代码执行） 与 API 凭据泄露缺陷。
Komari 的 2FA 认证绕过漏洞（GHSA-jhmr-57cj-q6g9） 等等。

加上很多玩家为了炫耀，直接用弱密码将带有远程执行权限的监控后台裸奔在公网，一旦被黑产全网扫描或遭遇 0day，名下所有小鸡瞬间变为别人的肉鸡。

Mosona Manager 的安全解题思路#

Mosona Manager 在设计上显然吸取了这些教训，采取了更克制、更偏向堡垒机思路的做法：

1. 纯 SSH 无 Agent 模式（Agentless）：内存运行、阅后即焚#

终端控制台 (Terminal)	添加服务器 (New Server)

既然只是监控资源和偶尔连接终端，为什么非要在目标机器上装第三方常驻守护进程？

工作原理：你只需向主控提供服务器的 SSH 端口与凭据（密码或私钥）。Hub 通过标准 SSH 登录并在系统的共享内存目录（/dev/shm）中写入经过优化的轻量采集脚本（linux_info.sh 与 linux_status.sh）。
零侵入与零残留：脚本采集完成后利用 shell trap 自动清理退出，目标机器上不安装任何常驻服务、不留任何二进制文件。
安全性：完全依托经历了几十年全球验证的标准 Linux SSH 协议和公钥认证机制，被控机不向公网暴露任何额外端口，也不承担第三方 Agent 的 RCE 风险。

当然，针对处于家庭宽带或 NAT 内网、无法开放 SSH 端口的机器，Mosona Manager 也保留了被动 Agent 模式（Agent 主动通过 WebSocket 反连 Hub）。

2. 凭据落库加密与 Host Key Pinning#

AES-GCM 信封加密：存储在数据库中的 SSH 密码与私钥采用基于上下文绑定的版本化 AES-GCM 加密，主密钥受严格的系统文件权限保护，杜绝数据库明文泄露。
主机公钥指纹锁定（Host Key Pinning）：纳管服务器时强制锁定目标机的 SSH 公钥指纹，有效防止内网欺骗或中间人劫持。

个人资料与通知偏好 (Profile)	系统管理与全局配置 (Admin)

3. 公开展示页与管理 API 物理级隔离#

实时时序监控图表 (Monitor)	独立公开状态页 (Public Page)

许多玩家既想对外分享探针，又担心后台泄露。Mosona Manager 支持配置独立的公开展示页（支持独立路径如 /preview/status，或绑定独立二级域名）：

中间件阻断：Hub 在路由层面会直接拦截所有来自公开展示页域名的后台管理 API。即使公开域名被爬虫扫爆，也碰不到任何管理接口。
数据流限流：公开展示采用 SSE（Server-Sent Events）推送，内置了针对单个 IP 的频率与并发连接保护。

配置公开展示页

完整部署实战 (Docker Compose)#

以下是在一台标准 Linux 服务器（推荐 Debian 12/13 或 Ubuntu 22.04/24.04）上，使用 Docker Compose 部署的完整流程。

1. 准备工作#

确保服务器已安装 Docker 与 Docker Compose：

1
curl -fsSL https://get.docker.com | bash -s docker
2
systemctl enable --now docker

2. 克隆仓库并修改 `.env`#

1
mkdir -p /opt/mosona && cd /opt/mosona
2
git clone https://github.com/mosona-labs/mosona-manager.git
3
cd mosona-manager/deploy
4
cp .env.example .env
5
nano .env

一份适合生产环境的标准 .env 文件如下（请将带有随机字符的密码全部替换为自己的强密码）：

1
# 镜像版本，默认保持 latest
2
APP_VERSION=latest
3

4
# Hub 监听端口与地址（绑定到 127.0.0.1 由反向代理接入）
5
APP_PORT=8080
6
APP_HOST=127.0.0.1
7

8
# 当通过 HTTPS 反向代理或 Cloudflare CDN 访问时，必须设为 true
9
SECURE_COOKIES=true
10

11
# Redis 访问凭据
12
REDIS_PASSWORD=YourStrongRedisPass_928371
13

14
# PostgreSQL 数据库配置
15
PG_DB=mm_db
16
PG_USER=mm_user
17
PG_PASSWORD=YourStrongPgPass_849201
18

19
# InfluxDB 2 初始化配置（时序数据库凭据）
20
INFLUX_USER=admin
21
INFLUX_PASSWORD=YourStrongInfluxPass_572910
22
INFLUX_ORG=mm_org
23
INFLUX_BUCKET=mm_bucket
24
INFLUX_TOKEN=YourVeryLongSecureInfluxToken_AtLeast32Chars123456

3. 启动容器群并做健康检查#

拉取镜像并启动：

1
docker compose --env-file .env -f compose.yml pull
2
docker compose --env-file .env -f compose.yml up -d

稍等片刻，各组件（PostgreSQL 18、Redis 7、InfluxDB 2.8、App Hub、Watchtower）会自动完成初始化。运行以下命令验证健康状态：

1
curl -fsS http://127.0.0.1:8080/health

若返回 {"code":"ok","msg":"Service is healthy"}，说明数据库与主控一切就绪。

4. 反向代理与安全配置#

强烈建议使用 HTTPS 反代，并禁止将 8080 端口直接暴露在公网。

方案一：Cloudflare Tunnel（零端口暴露，最安全）#

在 Cloudflare Zero Trust 控制台的 Tunnels 中添加一条路由，将你设定的管理域名（如 manager.example.com）直接代理到本机的 http://127.0.0.1:8080，免去了配置证书和开放防火墙端口的麻烦。

方案二：Nginx 配置#

若使用 Nginx，必须正确配置 WebSocket 升级头，以保证 Web SSH 终端与状态流正常：

1
server {
2
    listen 80;
3
    server_name manager.example.com;
4
    return 301 https://$host$request_uri;
5
}
6

7
server {
8
    listen 443 ssl http2;
9
    server_name manager.example.com;
10

11
    ssl_certificate /path/to/cert.pem;
12
    ssl_certificate_key /path/to/key.pem;
13

14
    location / {
15
        proxy_pass http://127.0.0.1:8080;
16
        proxy_http_version 1.1;
17

18
        # WebSocket 支持 (Web 终端与 SSE 所需)
19
        proxy_set_header Upgrade $http_upgrade;
20
        proxy_set_header Connection "upgrade";
21

22
        # 真实 IP 透传
23
        proxy_set_header Host $host;
24
        proxy_set_header X-Real-IP $remote_addr;
25
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
26
        proxy_set_header X-Forwarded-Proto $scheme;
27

28
        proxy_read_timeout 86400s;
29
        proxy_send_timeout 86400s;
30
    }
31
}

5. 首次初始化与必做安全配置#

打开浏览器访问配置好的域名，按照向导创建管理员账户并创建第一个 Team。

进入面板后，请务必前往 Admin Dashboard（管理后台） 检查以下设置：

基础 URL（Base URL）：填入完整的访问地址（如 https://manager.example.com/），阻断非本域名的恶意请求。
信任代理（Trust Proxy）：勾选 Trust CDN / reverse proxy headers。否则所有登录日志记录的 IP 都会是 127.0.0.1，会话 IP 绑定保护也会失效。
启用 2FA：在个人安全设置中绑定 TOTP 双因素认证，这是防止撞库的最有效防线。

搜索文章

告别传统探针：Mosona Manager 深度体验 —— 个人自用轻量堡垒机与监控新选择

个人自用的轻量 JumpServer#

避坑提醒：两点必须明确的硬性限制#

1. 没有延迟监测功能#

2. InfluxDB 是吃内存怪兽，不要低配小鸡部署#

为什么传统探针让人不安心？谈谈哪吒与 Komari 的安全隐患#

1. 侵入式常驻 Agent 的“高权限原罪”#

2. 被黑客当成现成 C2 后门滥用（Living-off-the-Land）#

3. 历史高危 CVE 频发#

Mosona Manager 的安全解题思路#

1. 纯 SSH 无 Agent 模式（Agentless）：内存运行、阅后即焚#

2. 凭据落库加密与 Host Key Pinning#

3. 公开展示页与管理 API 物理级隔离#

完整部署实战 (Docker Compose)#

1. 准备工作#

2. 克隆仓库并修改 `.env`#

3. 启动容器群并做健康检查#

4. 反向代理与安全配置#

方案一：Cloudflare Tunnel（零端口暴露，最安全）#

方案二：Nginx 配置#

5. 首次初始化与必做安全配置#

相关资源链接#

告别传统探针：Mosona Manager 深度体验 —— 个人自用轻量堡垒机与监控新选择

个人自用的轻量 JumpServer#

避坑提醒：两点必须明确的硬性限制#

1. 没有延迟监测功能#

2. InfluxDB 是吃内存怪兽，不要低配小鸡部署#

为什么传统探针让人不安心？谈谈哪吒与 Komari 的安全隐患#

1. 侵入式常驻 Agent 的“高权限原罪”#

2. 被黑客当成现成 C2 后门滥用（Living-off-the-Land）#

3. 历史高危 CVE 频发#

Mosona Manager 的安全解题思路#

1. 纯 SSH 无 Agent 模式（Agentless）：内存运行、阅后即焚#

2. 凭据落库加密与 Host Key Pinning#

3. 公开展示页与管理 API 物理级隔离#

完整部署实战 (Docker Compose)#

1. 准备工作#

2. 克隆仓库并修改 .env#

3. 启动容器群并做健康检查#

4. 反向代理与安全配置#

方案一：Cloudflare Tunnel（零端口暴露，最安全）#

方案二：Nginx 配置#

5. 首次初始化与必做安全配置#

相关资源链接#

2. 克隆仓库并修改 `.env`#