让 AI 帮你管服务器，但不交出 SSH 私钥

越来越多的人让 AI 帮忙看日志、改配置、重启服务。最顺手的做法是：在自己电脑上开一个能跑命令的 AI，让它 ssh 到服务器上操作。

这样确实能用，但有一件事值得停下来想一想：为了让 AI 能 ssh，你给它的其实是整个 ~/.ssh。

经本机 ssh：你给出的比你以为的多

AI 要在你的电脑上执行 ssh prod，就得能读取 ~/.ssh 里的配置和私钥。而一般的权限控制只能做到「能不能读这个文件夹」，做不到「只能连这一台机器」。这意味着：

• 它能读到的是所有私钥，不只是这台服务器的那一把。
• 只要命令还能联网，私钥就可能被带走。私钥一旦外泄就一直有效，事后关掉 AI 的权限也收不回来，只能去每台服务器上删公钥。
• ssh 登录成功之后，服务器上能做什么，取决于那把 key 对应的账户。如果那是 root，AI 拿到的就是 root。

服务器日志里也只会看到「你的电脑用你的 key 登录了」，分不出是你在操作还是 AI 在操作。

换个方向：让服务器自己连回来

不让 AI 拿着钥匙去开服务器的门，而是在服务器上装一个小程序，让服务器主动连到你的 AI 账号，再由你决定 AI 能做什么。

用 Frely 时就是这样：

1. 在 Frely 网站的 My Devices → Add a computer 生成一条一次性安装命令，粘到服务器上运行。这个令牌只能用一次，15 分钟后过期，也不会保存在服务器上。
2. 服务器主动向外连接 Frely，不需要开任何端口。
3. 在 ChatGPT、Claude 或 Codex 里接上 FrelyMCP，AI 就能在这台服务器上看文件、跑命令。

这样做的好处：

• 没有长期私钥交给 AI。 服务器用的是只属于它自己的设备身份，AI 跑的命令读不到它。
• 命令默认在沙箱里跑。 只能写你指定的目录和临时目录，~/.ssh、~/.aws 这类凭据目录读不到。服务器跑不了沙箱时，命令会被直接拒绝，而不是悄悄在没有保护的情况下执行。
• AI 想要更多权限，必须由你批准。 它会发起请求，你在 Frely 网站上用 passkey 或验证器验证后决定给不给、给多久：只放行这一条命令、12 小时，或者一直到设备授权结束。AI 不能批准自己的请求。
• 随时撤销，立即生效。 每一次调用都会重新检查授权，你撤销之后，下一条命令就过不去了。

想更稳一点：四个习惯

装在服务器上，安全边界就是「运行它的那个系统用户 + 沙箱」，所以这几件事决定了它到底有多安全：

1. 用一个专用的普通用户安装，不要用 root。 比如新建 frely-ops，只给它应用目录的权限。沙箱限制的是写入，不限制这个用户本来能读什么，所以用户本身的权限越小越好。想不用 root 读系统日志，可以把它加进 adm 和 systemd-journal 组。
2. 确认沙箱可用。 Linux 上装好 bubblewrap、socat 和 ripgrep，用 frely doctor 检查沙箱是否可用。CentOS 7 这类老系统跑不了沙箱，这时按需批准一段时间的「关闭沙箱运行」，不要一直开着。
3. 只共享需要的目录。 用 FRELY_WORKSPACE=/srv/myapp 指定，不要把整个家目录交出去；设备授权的天数也尽量取短。
4. 清楚 docker 组意味着什么。 在 docker 组里的用户可以直接读 docker logs，很方便，但这个组的权限等同于 root。

什么时候仍然可以用 ssh

如果你只让 AI 读日志、跑几个只读命令，经本机 ssh 也可以接受，前提是：

• 为这台服务器单独生成一把 key，在服务器的 authorized_keys 里加上 from=、restrict 等限制，并且只登录到受限用户；
• ~/.ssh 里不要同时放其他高权限的 key；
• 只为手头的任务临时放行，不要一开就是好几天。

小结

让 AI 运维服务器，关键不是 AI 有多聪明，而是它手里拿着什么。与其把钥匙交给 AI，不如让服务器自己连回来，由你决定它能做什么。

开始使用 Frely CLI