为什么草根站长需要"网页化的服务器管理"
一个人维护两三台 VPS，最怕的不是技术难，而是"忘记命令"。上周能敲出来的 iptables -t nat -L -n --line-numbers，这周要重启防火墙时又得翻半天笔记；半夜监控报警说磁盘满了，手机 SSH 客户端打字又慢又容易错。这些年我自己从纯命令行一路折腾过来，直到把 Cockpit 装到每台机器上，日常巡检、看日志、重启服务、查磁盘，基本都在浏览器里点几下就完成，真正需要敲命令的只剩复杂排障。
这篇文章不讲概念，讲的是我在内网三台机器上真实跑通的 Cockpit 部署流程：装什么包、怎么开 9090、怎么用一套 Web 界面同时管多台机器、怎么把它的 root 权限收住，以及几个我踩过的坑。读完你可以直接照抄。
Cockpit 到底是什么，和宝塔、Webmin 有什么不同
Cockpit 是 Red Hat 主导开发的开源项目，定位是"给 Linux 服务器配一个原生 Web 控制台"。它的关键特点有三个，也是我最终选它的原因：
- 不接管系统。宝塔这类面板会自己装一套 Nginx/PHP/MySQL 运行环境，跟你原有的软件包打架。Cockpit 只是调用系统已有的 systemd、journald、firewalld、storage 接口，你原来怎么装的，它还怎么用。
- 凭证即系统账号。它没有独立的用户名体系，登录用 PAM，也就是直接用 Linux 系统的用户和密码。你在服务器上怎么分权，网页上就怎么分权。
- 可选装多机管理。装一个 cockpit-dashboard（新版合并进主包叫 Cockpit "Multi-server"）就能在一个界面里加进其他服务器，切标签页管理。
Webmin 更老、功能更杂，但它的模块是 Perl 手写的，界面风格停留在十几年前，而且很多配置操作会在你不知道的情况下直接改配置文件，出问题很难回溯。Cockpit 的每一次操作都会落到系统日志里，可追溯性好得多。
第一步：安装 Cockpit 主体
Debian / Ubuntu 系：
apt update
apt install cockpit -y
# 多机管理面板（可选）
apt install cockpit-ws cockpit-system -yRHEL / CentOS / Rocky 系：
dnf install cockpit -y
# 若要管多台机器，前端机器还需要
dnf install cockpit-dashboard -y # 老版本；新版已内置于 cockpit-ws装完之后检查服务状态，并设为开机自启：
systemctl enable --now cockpit.socket
systemctl status cockpit.socket注意这里启用的是 cockpit.socket 而不是 cockpit.service。Cockpit 用的是 systemd 的 socket 激活：平时没有连接时，Web 服务进程是不常驻内存的，只有浏览器真正连上 9090 端口，systemd 才把 cockpit-ws 拉起来。这在低配 1G 内存的小鸡上非常友好，白天空闲时几乎零内存占用。
第二步：放行 9090 端口，并且只放给该放的人
Cockpit 默认监听 9090。如果你用的是 firewalld：
firewall-cmd --permanent --add-service=cockpit
firewall-cmd --reload如果用 ufw：
ufw allow 9090/tcp
ufw reload⚠️ 这里有个安全大坑：千万不要把 9090 直接暴露到公网。Cockpit 登录后基本等于系统超级权限，一旦密码被爆破，整台机器就没了。我的做法是二选一：
- 云厂商安全组只放行自己家宽 IP，其余全部拒绝；
- 或者 9090 只监听 127.0.0.1，通过 SSH 端口转发访问。
第二种最安全，具体做法是编辑 /etc/cockpit/cockpit.conf：
[WebService]
Origins = https://localhost:9090 https://127.0.0.1:9090然后本地终端执行 ssh -L 9090:127.0.0.1:9090 root@your-server，浏览器打开 https://localhost:9090 即可。这样 Cockpit 在网络层面上根本不存在，攻击者扫不到。
第三步：用 Multi-server 一套界面管多台机器
这是 Cockpit 相比宝塔最实用的功能。假设你有 A、B、C 三台机器，在 A 上装好 Cockpit 并登录，点左上角菜单的"添加服务器"，填入 B 的 IP、用户名和密码即可。
底层原理是：A 上的 cockpit-ws 作为前端，通过 SSH 通道连到 B 的 9090，代理转发所有请求。所以：
- B、C 上也必须装 cockpit 包并启动 cockpit.socket，但它们的 9090 不需要对公网开放，只要能被 A 通过内网 SSH 到即可；
- A 到 B 走的是 SSH，所以目标机器的
sshd必须允许密码或密钥登录； - 如果 B 只允许密钥登录（推荐），在添加服务器时选择"使用 SSH 密钥"，或者干脆在 A 上生成密钥并分发。
生成并分发密钥的完整流程：
# 在 A 上生成（若无）
ssh-keygen -t ed25519 -C "cockpit-a"
# 分发到 B
ssh-copy-id root@10.0.0.12
# 测试免密
ssh root@10.0.0.12 'hostname'常用功能实操：把日常巡检搬进浏览器
系统总览与实时资源
登录后首页就是 Overview，CPU、内存、磁盘、网络四张实时曲线图，鼠标悬停能看到具体数值。比起 top 不停刷屏，这里一眼就能看出是哪一项长期偏高。我每天早上第一件事就是扫一眼三台机器的内存曲线，有没有爬升趋势一目了然。
journalctl 日志图形查询
点"日志"菜单，本质上是 journald 的可视化。可以按服务、按优先级（错误/警告）过滤，也支持关键字搜索。以前排查"某服务为什么重启"要敲 journalctl -u nginx --since "1 hour ago"，现在选择单元、选时间范围就行，还能直接导出。
服务与定时器管理
"服务"页列出所有 systemd 单元，启停、重启、设为开机自启都是按钮操作。修改 unit 的启动参数也能在界面上做，改完自动 daemon-reload。对经常要重启某个自研 Go 服务的站长来说，手机上就能操作。
存储与磁盘
"存储"页能看分区、挂载点、I/O 活动，还支持创建 LVM 卷组、扩展逻辑卷、挂载磁盘。我扩容云盘后就是在这里直观看到新分区挂上来的，不用记 lsblk 的参数。
终端与文件管理
Cockpit 内置一个 Web 终端，登录后默认就是你当前的系统用户身份。还有文件管理器，可以直接上传下载编辑配置。改 Nginx 配置时我常用它——浏览器里改完直接保存，比 SFTP 客户端快。
权限收口：别让每个登录的人都变成 root
Cockpit 的权限完全跟随系统账号。所以最正确的做法不是"给所有人 root"，而是建普通账号、按需提权：
# 建一个只有基础查看权限的账号
useradd -m -s /bin/bash ops
passwd ops
# 若需要它能重启服务，用 sudo 白名单而非给 root
echo 'ops ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx, /bin/systemctl restart php8.2-fpm' \
> /etc/sudoers.d/ops-cockpit
chmod 440 /etc/sudoers.d/ops-cockpit
visudo -c另一个关键开关是 Cockpit 的"管理访问"（Administrative access）。默认情况下，普通用户登录后，页面上凡是需要 root 的操作会弹出一个"以管理员身份重新认证"的对话框，要求你输入 root 或具备 sudo 权限的账号密码。如果你不希望有这个提权入口，可以在 cockpit.conf 里关闭：
[WebService]
AllowUnencrypted = false
[Log]
[Session]
Banner = 仅限授权运维人员访问我踩过的五个坑
- 证书告警。Cockpit 自签证书，浏览器每次提示不安全。可以把它换成 Let's Encrypt 证书，或在内网自建 CA 导入信任，否则每次登录要点"继续前往"很烦。
- socket 没启对。只
systemctl start cockpit不生效，必须启用的是cockpit.socket，否则 9090 根本没人监听。 - 多机连接失败。90% 是目标机
sshd_config里PasswordAuthentication no且没有配密钥，或者目标ip 的安全组没放 A 机器的内网地址。 - 页面报 "Connection failed"。多半是 SELinux 或 AppArmor 拦了 cockpit-ws 的某个操作，可以先
journalctl -u cockpit看具体拒绝项，再针对性放行，不要图省事整体关掉 SELinux。 - 版本太老。Debian 自带源里的 Cockpit 往往落后一两个大版本，菜单里没有"多机"入口。这种情况可以加官方源升级，或直接用 RHEL 系发行版。
进阶玩法：用 Cockpit 自带的 Podman 面板管容器
Cockpit 还有个容易被忽略的组件叫 cockpit-podman，装上之后浏览器里会多出一个"Podman 容器"菜单，可以图形化地查看容器状态、看日志、拉镜像、甚至进容器终端。对不习惯敲一长串 docker ps -a --format 的站长来说，这是排查容器为什么起不来的最快方式。
apt install cockpit-podman -y # Debian/Ubuntu
dnf install cockpit-podman -y # RHEL 系需要注意的是它对接的是 Podman 而非 Docker。如果你原来用的是 Docker，可以两者共存——Cockpit 管不了 Docker 容器，但也不干扰 Docker 运行。想彻底省心的话，把简单的自建服务逐步迁到 Podman，就能在同一个界面里既看系统又看容器。
配合防火墙与 fail2ban 做最后一道防线
即使 9090 只对特定 IP 开放，我依然会在服务器上再叠一层保护。以 fail2ban 为例，加一个针对 Cockpit 登录失败的 jail：
# /etc/fail2ban/jail.d/cockpit.local
[cockpit]
enabled = true
port = 9090
filter = cockpit
logpath = /var/log/cockpit/cockpit.log # 路径以实际为准
maxretry = 5
bantime = 3600原理是读取 Cockpit 的登录日志，连续失败五次就把来源 IP 封一小时。这样即便你的 IP 白名单不小心配宽了，暴力破解也会在几次尝试后被自动挡住。记得改完 systemctl restart fail2ban 并用 fail2ban-client status cockpit 确认 jail 已加载。
多机场景下的密钥管理建议
用 Multi-server 管多台机器，本质是让主控机用 SSH 连被管机。这里有个安全权衡：如果主控机被攻破，它到所有被管机的密钥就全暴露。我的建议是给 Cockpit 单独生成一对专用密钥，且只允许它登录一个权限受限的账号，而不是 root：
# 被管机上，把专用公钥限制为只能从主控机使用
# 在 /home/ops/.ssh/authorized_keys 前加限制
from="10.0.0.11",command="/usr/bin/restricted-shell" ssh-ed25519 AAAA... cockpit-a虽然 command= 会限制 Cockpit 的部分功能，但至少挡住了密钥被挪作他用。更彻底的做法是用 SSH 证书在有效期和用途上做约束，那属于进阶话题了。对大多数个人站来说，"非 root 账号 + 密钥 + IP 来源限制"已经足够。
小结与取舍建议
如果你的诉求是"给网站搭一套傻瓜化的 LNMP 环境"，宝塔仍然更省事。但如果你是一个已经会用命令行的站长，只是想让日常巡检、看日志、重启服务这些重复劳动更顺手，同时又不希望一个第三方面板接管你的系统，那 Cockpit 是目前最干净的选择。它不改变系统，只提供一个视图；权限用的是系统账号，安全边界和 SSH 一致；socket 激活让它在低配机器上几乎不占资源。
我的建议是：主控机上装全套并开放 9090（限 IP），被管机器上只装 cockpit 包、9090 不开公网，走 SSH 内网连接。这样即使某一台的 Web 端口被人碰到，也打不开你那台真正的"大脑"。