Hermes Agent 进阶教程：服务器安全防护 3 项必做 + GitHub 自动化备份，打造密不透风的安全屋

用 Hermes Agent 的人越来越多，但有个问题几乎没人认真对待：安全。

你的聊天记录、个人信息，甚至密码和 API 密钥，如果不做基础检查和配置，随时处在暴露风险中。而一个能跑 shell 命令、能读写文件的 AI Agent 一旦被攻破，后果比普通网站被黑严重得多。

这篇教程分两部分，把你的 Hermes Agent 打造成密不透风的安全屋：第一部分做服务器安全加固，第二部分做数据自动化备份。 不会复杂命令也没关系——文中所有操作都附提示词，直接丢给 AI 执行。但注意事项一定要先读完再动手。

第一部分：服务器安全三项必做

最可怕的不是服务器出了问题，而是出了问题你还不自知。公网环境极其恶劣：默认 22 端口 + 密码登录，就是黑客脚本的重点扫描对象。想不沦为肉鸡，以下三项必做。

第 1 项：修改 SSH 默认端口

把默认的 22 端口改为 20000-65535 之间的高位端口，可以规避 99% 的无差别自动化扫描。

提示词（直接发给 AI）：

请检查当前 Linux 系统和 SSH 配置，备份配置文件后，从 20000-65535 中选择一个未占用的端口并修改 SSH 配置。先放行新端口并暂时保留 22 端口，执行配置检查后重新加载 SSH，确认新端口正在监听。最后给出新端口的登录测试命令和回滚方法；遇到错误立即停止。

注意提示词里的两个安全设计：暂时保留 22 端口（新端口验证成功前不断后路）、要求给出回滚方法（改错了能恢复）。

第 2 项：禁用密码登录，改用密钥认证

密码泄露是服务器失守的最大入口。配置 SSH 密钥对，只允许持有私钥的客户端登录，彻底关闭密码验证——密钥登录基本杜绝了撞库和暴力扫描。

提示词：

请检查当前用户的 SSH 公钥和 authorized_keys 权限。如果没有公钥，指导我在本地生成 Ed25519 密钥，我只会提供公钥，绝不提供私钥。备份 SSH 配置，启用密钥认证；等我在另一个终端确认密钥登录成功后，再关闭密码和交互式认证。修改后检查配置、重新加载服务，并给出验证结果和回滚方法。

两个关键点：Ed25519 算法（比传统 RSA 更短更安全）；绝不把私钥发给 AI——只提供公钥，私钥永远留在本地。

第 3 项：配置防火墙 + Fail2Ban

启用 UFW 防火墙放行新端口，启用 Fail2Ban 监控 SSH 日志，自动封禁多次试错的恶意 IP。

提示词：

请检查服务器当前的防火墙、SSH 端口和正在使用的业务端口。备份现有规则，先放行新的 SSH 端口和必要业务端口，再启用 UFW，设置为默认拒绝入站、允许出站。随后安装并配置 Fail2Ban 保护新的 SSH 端口，使用 maxretry=5、findtime=10m、bantime=1h，并检查防火墙、Fail2Ban 和 SSH 是否正常。不要覆盖现有规则，最后给出配置结果和回滚方法。

配置思路：默认拒绝入站、允许出站（最小权限原则），Fail2Ban 参数 maxretry=5、findtime=10m、bantime=1h（10 分钟内错 5 次封 1 小时）。

⚠️ 动手前必读（防踩坑清单）

• 不要关闭当前 SSH 窗口——在另一个终端确认新端口和密钥能正常登录后再操作
• 云服务器要在安全组放行新端口（很多人改了端口忘了安全组，直接把自己锁外面）
• 新登录方式验证成功前，不要关闭 22 端口或密码登录
• 私钥绝不发给 AI
• 执行前先创建服务器快照，或确保能通过云厂商控制台救援模式恢复

第二部分：GitHub 自动化备份

天灾人祸不可避免——哪怕服务器在云端，也可能故障导致数据不可用。备份方式很多，但最安全高效的是 GitHub 仓库：

1. 一个邮箱即可注册，提供账号和 API Key 两种授权，官方工具 gh 接口完善，AI 可以自主完成全部操作
2. GitHub 本身就是 AI 使用者的必备技能——海量开源工具和项目都在上面

安装：sudo apt install gh

登录账户（两种方式）

方式一：账户授权（简单）——gh auth login，选 GitHub → HTTPS 浏览器授权，页面会给出 URL 和 Code，在已登录 GitHub 的浏览器里输入 Code 即可。适合单项目用户；多账户多项目不推荐（权限过大容易互相污染）。

方式二：Fine-grained API Key（精细）——GitHub 设置 → Developer settings → Personal access tokens → Fine-grained tokens，可精确控制 Key 的权限范围、项目范围和有效期，然后 gh auth login 选 Auth Token 填入。颗粒度细，适合多项目。

备份范围划分（关键一步）

不能什么都往仓库塞——效率低，而且单个 GitHub 仓库有容量上限。原则一句话：

备份"手工维护、唯一且不可重新产生"的资产；不备份"运行时自动生成"的东西。

✅ 需要备份：

这些每一项都独一无二，丢了基本无法还原。

❌ 不需要备份：

.env（含密钥，基于保密不推荐备份）、auth.json（授权信息）、sessions/（聊天记录，想回溯可单独备）、logs/、cache/、executions.db、ticker/lock 文件、node/lsp 依赖产物。

设置自动化备份任务

范围划好后，一句话让 Hermes Agent 设置每天凌晨 3 点的定时任务。提示词：

每天对 Hermes 做一次轻量配置备份，只保留可重建能力，不备份运行时垃圾和敏感凭据。

备份范围：
1. 主 profile 的 SOUL.md 和 config.yaml
2. 其他 profile 的 SOUL.md 和 config.yaml（如果存在）
3. ~/.hermes/skills/
4. ~/.hermes/scripts/
5. wiki 目录
6. ~/.hermes/vault/opinions/（如果存在）
7. 各 profile 的 cron/jobs.json（如果存在）

不要备份：.env、auth.json、sessions/、state.db、logs/、cache/、executions.db、ticker/lock 文件、node/lsp/安装产物

执行要求：
- 目标仓库：/root/hermes-backup
- 用同步方式覆盖旧内容，源不存在就删除目标对应文件
- git add -A；只有有变更时才 commit 和 push
- commit message: auto backup YYYY-MM-DD_HH:MM
- 失败时输出明确错误，不要静默吞掉

一个真实的踩坑教训

原教程作者特别强调：配置好后，隔天一定要去 GitHub 仓库确认备份真的成功了。

他自己就踩过坑——定时任务设置后实际没执行成功，但没有输出任何报错，导致他一直以为备份在正常跑。所以提示词最后那句"失败时输出明确错误，不要静默吞掉"不是客气话，是血泪教训。

写在最后

只有经历过数据丢失或服务器被黑的人，才知道这两件事的重要性。

三项安全加固（高位端口 + 密钥认证 + 防火墙 Fail2Ban）防住的是"进来的贼"，自动化备份防住的是"意外的灾"。两套配置各花半小时，换来的是之后每一天的安心。

不要等出了问题再找补救方法——未雨绸缪，永远给自己留后手。