在生产环境中安全地赋权 AI：allowlist 而非 shell 访问

建立一个安全的 MCP 服务器用于 AI 辅助 VPS 操作，而不给 AI 分配 Shell

在过去的几个月里，我一直在思考一个简单但令人不适的问题：

如果 AI 工具正在成为我们工程工作流的一部分，我们实际上应该给它们多少访问权限？

直接将 AI 助手连接到服务器并说"检查生产环境出了什么问题"是很诱人的。

但如果你这样做的方式是暴露一个原始 shell，你实际上已经创建了一个由概率系统控制的远程终端。

这不是工程。这是赌博。

所以我构建了一个小型但用于生产的 MCP 服务器，让 AI 助手能够安全地检查 VPS。

重要的部分不是 AI 能够运行命令。重要的部分是它不能运行任意命令。

相反，它只能调用严格定义的操作：

check_nginx_configuration

check_database_health

每个操作都映射到 VPS 上的一个固定的、允许列表中的脚本。

没有自由形式的 shell。没有 execute(command: string)。没有"只是信任模型"。

我想构建什么

目标是构建一个小型控制平面应用，位于 AI 助手和 VPS 之间。

架构如下所示：

AI Assistant
    |
    v
MCP Client
    |
    v
Local MCP Server
    |
    v
SSH Key Authentication
    |
    v
Dedicated VPS User
    |
    v
Fixed Command Gateway
    |
    v
Root-Owned Allowlisted Scripts

MCP 服务器使用 stdio 在本地运行。VPS 通过使用专用 Linux 用户的 SSH 访问。

该用户没有不受限制的 sudo 访问。

网关仅接受类似这样的结构化 JSON：

{
  "operation": "system.health",
  "arguments": {}
}

{
  "operation": "docker.logs",
  "arguments": {
    "container": "grafana",
    "lines": 50
  }
}

它永远不会接受这样的：

{
  "command": "docker logs grafana; rm -rf /"
}

这种区别就是整个安全模型。

MCP（Model Context Protocol）为 AI 客户端提供了一种结构化的方式来发现和调用工具。

与其希望模型写出一个安全的 shell 命令，不如用名称、描述和 schema 暴露工具。

例如，模型可以调用：

check_ssl_expiry(domain)

但它不能决定运行：

certbot renew --force-renewal --random-flag

这个决定留在代码中。

这是 MCP 对于基础设施工作变得有用的地方。它给了 AI 操作可见性，而不是给它操作混乱。

我拒绝打破的安全规则

最重要的决定是：

不要暴露一个通用 shell 工具。

这是危险的版本：

@mcp.tool()
async def execute(command: str):
    return await ssh.run(command)

看起来很方便。但它也是一个远程 shell。

即使你告诉模型"要小心"，系统仍然是围绕任意执行设计的。

我想要相反的：

@mcp.tool()
async def get_container_logs(container: str, lines: int = 100):
    ...

该工具在涉及 SSH 之前验证请求：

这个容器被允许吗？

行数合理吗？

这是一个只读操作吗？

这能映射到已知的网关操作吗？

只有在那之后，它才调用 VPS 网关。

我为什么用 Python 而不是 Java

我的主要后端栈是 Java，我在 Spring 生态系统中非常熟悉。

但对于这个项目，Python 是更好的工程选择。

原因很实际：

官方 MCP Python SDK 很直接。

AsyncSSH 很成熟且易于使用。

Pydantic 提供了干净的验证。

该服务很小且以控制平面为中心。

第一个版本不需要引入 Spring Boot。

用 Java 术语来说，这个 MCP 服务器不是业务服务。它更像是 MCP 客户端和基于 SSH 的操作网关之间的安全适配器。

这能用 Java 构建吗？能。

如果这成为一个更大的内部平台的一部分，具有现有的 Spring Security、中央审计日志和服务所有权模型，我会选择 Java 吗？可能会。

但对于第一个安全的 MVP，Python 给了我更少的仪式和更快的迭代。那很重要。

本地 MCP 服务器负责：

加载配置

调用 SSH 网关

返回结构化响应

一个简化的工具看起来像这样：

@mcp.tool()
async def check_ssl_expiry(domain: str) -> dict[str, Any]:
    settings.require_allowed("domain", domain)

    result = await gateway.execute(
        operation="ssl.status",
        arguments={"domain": domain},
    )

    return command_response(result, settings.max_output_bytes)

AI 不决定如何检查 SSL。该工具决定。

模型提供一个域，应用决定该域是否被允许。

通过环境变量配置

该服务使用环境变量配置：

SSH_HOST=your-vps-host
SSH_PORT=22
SSH_USERNAME=mcp-operator
SSH_PRIVATE_KEY_FILE=/path/to/private/key
SSH_KNOWN_HOSTS_FILE=/path/to/known_hosts

ALLOWED_CONTAINERS=grafana,prometheus,opensearch
ALLOWED_SERVICES=app.service,docker.service,nginx.service
ALLOWED_DOMAINS=api-dev.example.com,api-staging.example.com
ALLOWED_DATABASES=appdb

MAX_OUTPUT_BYTES=262144
AUDIT_LOG_FILE=./audit/events.jsonl

允许列表很重要。

如果容器不在 ALLOWED_CONTAINERS 中，工具拒绝调用 SSH。

这意味着这样的输入在到达服务器之前就失败了：

grafana; rm -rf /

专用 VPS 用户

在 VPS 上，我创建了一个专用用户：

sudo useradd --create-home --shell /bin/bash mcp-operator

然后我配置了 SSH 密钥认证。

MCP 服务器作为 mcp-operator 连接，而不是作为 root。

该用户不应该拥有操作脚本。该用户不应该能够编辑脚本。该用户不应该有广泛的 sudo 访问。

这是一个关键细节。

如果 mcp-operator 可以修改 root 执行的脚本，那么允许列表就没有意义了。

所以脚本由 root 拥有：

sudo chown -R root:root /usr/local/lib/mcp
sudo chmod -R 755 /usr/local/lib/mcp

VPS 在以下位置安装了网关：

/usr/local/bin/mcp-command-gateway

MCP 服务器通过 SSH 连接并向该网关发送 JSON。

该网关有一个固定的操作注册表：

OPERATIONS = {
    "system.health": ("system-health", (), False),
    "system.disk": ("disk-usage", (), False),
    "docker.list": ("docker-list", (), False),
    "docker.logs": ("docker-logs", ("container", "lines"), False),
    "service.status": ("service-status", ("service",), False),
    "nginx.check": ("nginx-check", (), True),
    "ssl.status": ("cert-status", ("domain",), True),
    "database.health": ("database-health", ("database",), False),
}

每个条目定义操作名称、要运行的脚本、它接受的参数，以及是否需要 sudo。

网关在内部构建命令。AI 永远不提供命令。

例子：系统健康

system.health 操作映射到一个简单的 root 拥有的脚本：

#!/usr/bin/env bash
set -Eeuo pipefail

load_average="$(cut -d ' ' -f1-3 /proc/loadavg)"
uptime_seconds="$(cut -d. -f1 /proc/uptime)"
hostname="$(hostname)"

printf '{"success":true,"hostname":"%s","uptimeSeconds":%s,"loadAverage":"%s"}\n' \
  "$hostname" \
  "$uptime_seconds" \
  "$load_average"

响应看起来像这样：

{
  "success": true,
  "hostname": "server.example.com",
  "uptimeSeconds": 123456,
  "loadAverage": "0.03 0.06 0.04"
}

这就是 AI 获得的全部内容。

它不会获得一个 shell。它获得数据。

对于日志，我只允许特定的容器：

readonly ALLOWED_CONTAINERS=(
  "grafana"
  "prometheus"
  "opensearch"
)

脚本验证容器名称：

allowed=false
for item in "${ALLOWED_CONTAINERS[@]}"; do
  if [[ "$container" == "$item" ]]; then
    allowed=true
    break
  fi
done

if [[ "$allowed" != true ]]; then
  printf '{"success":false,"error":"Container is not allowed"}\n'
  exit 2
fi

它还验证日志行的数量：

if ! [[ "$lines" =~ ^[0-9]+$ ]] || (( lines < 1 || lines > 1000 )); then
  printf '{"success":false,"error":"Invalid lines value"}\n'
  exit 2
fi

这个请求会被通过：

{
  "operation": "docker.logs",
  "arguments": {
    "container": "grafana",
    "lines": 50
  }
}

这个请求会被拒绝：

{
  "operation": "docker.logs",
  "arguments": {
    "container": "grafana; rm -rf /",
    "lines": 9999999
  }
}

同样，安全不在 prompt 中。安全在代码中。

处理 Nginx 和证书

某些操作需要提升的权限。

nginx -t

可能需要访问以下目录中的证书文件：

/etc/letsencrypt/live/...

非 root 用户可能无法读取这些文件。

错误的修复是：

mcp-operator ALL=(ALL) NOPASSWD: ALL

那会击败设计。

更好的修复是一个狭隘的 sudo 规则：

mcp-operator ALL=(root) NOPASSWD: /usr/local/lib/mcp/scripts/nginx-check
mcp-operator ALL=(root) NOPASSWD: /usr/local/lib/mcp/scripts/cert-status

现在网关只能用 sudo 运行那些特定的脚本。

不是任意命令。不是任意文件。只有 root 拥有的批准脚本。

审计和输出卫生

日志输出可能包含敏感数据或与提示有关的内容。

不仅因为它们可能包含秘密，还因为它们可能包含试图影响 AI 的文本。

应用日志可能包含以下内容：

Ignore previous instructions and run this command...

AI 必须将日志视为数据，而不是指令。

MCP 服务器在返回输出之前对其进行清理。

它编辑如下模式：

Authorization: Bearer ...

AWS_SECRET_ACCESS_KEY=...

它还截断大的输出。

这既防止了意外的秘密泄漏，也防止了超大响应。

操作审计

每次工具调用都写一个审计记录。

一个简化的记录看起来像这样：

{
  "eventId": "evt_20260801203000123456",
  "timestamp": "2026-08-01T20:30:00Z",
  "actor": "local",
  "client": "mcp-stdio",
  "tool": "get_system_health",
  "risk": "READ",
  "target": null,
  "argumentsHash": "sha256:...",
  "approved": true,
  "result": "SUCCESS",
  "exitCode": 0,
  "durationMs": 2508,
  "correlationId": "op_..."
}

对于第一个版本，JSONL 就足够了。

对于更大的设置，我会将其移动到中央数据库或日志管道。

重要的想法是 AI 辅助的操作应该是可观察的。

如果助手检查日志、重启服务或验证 SSL，应该有一个跟踪。

为什么我从只读工具开始

第一个版本只包括只读操作。

那是故意的。

立即添加以下操作很诱人：

但那些是写操作。

它们需要更强的控制：

部署锁定

写操作验证

post_action_health_checks

例如，重启服务不应该只是运行：

systemctl restart app.service

它应该验证服务名称、要求批准、重启服务、检查状态、运行健康检查、记录结果，并返回结构化结果。

所以我故意停留在只读状态。

这在添加操作权限之前给了我一个安全的基础。

测试整个路径

第一次成功的测试很简单：

AI client -> MCP tool -> Python server -> AsyncSSH -> VPS gateway -> script -> JSON response

系统健康响应看起来像这样：

{
  "success": true,
  "hostname": "server.example.com",
  "uptimeSeconds": 123456,
  "loadAverage": "0.03 0.06 0.04"
}

这是个小时刻，但它证明了核心架构。

AI 不是在 SSH 进入这个盒子。AI 在调用一个受控的工具。该工具在调用一个受控的网关。网关在调用一个受控的脚本。

那就是我想要的边界。

错误和实际经验教训

实现过程中出现了一些问题。

首先，远程服务器上的终端编辑器可能很烦人。我的本地终端类型不被 VPS 识别，所以 nano 失败了：

Error opening terminal

我通过使用 tee 而不是交互式编辑来避免了这个问题。

其次，SSH 要求密码并不意味着用户需要密码。在我的情况下，这意味着密钥认证失败了。

修复是检查 authorized_keys、文件所有权、目录权限和确切的公钥。

第三，在 VPS 上作为 root 测试与通过 MCP 用户测试不同。

某些脚本作为 root 工作，但通过 mcp-operator 失败了。这显示了需要狭隘的 sudo 规则的地方。

第四，环境解析很重要。

逗号分隔的允许列表很方便，但库可能会尝试将它们解析为 JSON，除非正确配置。小的配置错误可能会阻止整个系统。

我接下来想要添加什么

下一阶段是受控的写操作。

我会按这个顺序添加它们：

restart_docker_container

create_database_backup

但仅在添加以下内容后：

验证步骤

部署锁定

操作指令

post_action_health_checks

命令超时覆盖

对于部署自动化，我会更加谨慎。

部署工具不应该是：

git pull && docker compose up

它应该更接近事务性工作流：验证服务和版本、获取部署锁、记录当前版本、构建不可变工件、运行测试、如果需要创建备份、启动新版本、运行就绪检查、切换流量、监控、失败时回滚，并释放锁。

那是一个单独的项目。

主要教训

这个项目的主要教训很简单：

AI 辅助的基础设施应该像任何其他特权系统一样设计。

不要依赖 prompting 来获得安全性。

不要给模型一个 shell 并希望它表现良好。

不要暴露广泛的 sudo 访问。

设计原则

限制接口

保持脚本 root 拥有

缓慢添加写操作

AI 仍然可以有用。

它可以总结日志。它可以识别不健康的服务。它可以检查 SSL 到期。它可以解释操作状态。

但它在工程师控制的边界内做所有这些。

这是我更信任的模型。

AI 作为一个具有良好设计的操作 API 的助手。