authorizedkeyscommand 可实现 ssh 公钥动态加载，需 openssh ≥6.1、启用 pubkeyauthentication、禁用 authorizedkeysfile，并配置严格权限与安全审计的专用脚本。

要用 AuthorizedKeysCommand 从云端动态加载公钥，核心是让 SSH 服务在每次认证前，实时调用一个外部命令去查用户对应的公钥——不是读本地文件，而是对接你的密钥管理系统、数据库或 API 服务。

配置 AuthorizedKeysCommand 的关键前提

确保 OpenSSH 版本 ≥ 6.1（CentOS 7+/RHEL 8+ 默认满足）；若用较老系统（如 CentOS 6），需确认已打 Red Hat 补丁支持 AuthorizedKeysCommand 或 AuthorizedKeysCommandRunAs。

• sshd 必须启用公钥认证：PubkeyAuthentication yes
• 禁用传统静态文件路径：AuthorizedKeysFile none（显式关闭默认读取 .ssh/authorized_keys）
• 命令路径必须可执行且权限严格（建议放在 /usr/libexec/openssh/ 下，属主 root:root，权限 755）

AuthorizedKeysCommand 脚本编写要点

脚本接收唯一参数 $1（登录用户名），必须输出**严格单行**的公钥字符串（如 ssh-rsa AAAA... user@host），末尾不能有空格、换行、注释或空行，否则 SSH 解析失败。

• 开头加 set -euo pipefail，防止空用户名或网络错误导致静默失败
• 查询逻辑应基于用户名，例如：curl 调用内部 REST API、查询 PostgreSQL 用户表、读取 S3 上按用户名命名的公钥对象
• 所有敏感操作（如数据库连接）必须使用专用低权限账号，避免用 root 运行
• 务必设置 AuthorizedKeysCommandUser 为普通用户（如 ssh-keymgr），否则脚本以 root 身份运行，可能越权访问家目录或数据库凭证

安全与审计强化配置

动态加载不等于放松管控，反而更需明确责任边界和行为留痕。

• 每个返回的公钥行末尾追加注释，包含来源（如 # from vault-v2@2026-05-09T10:15:22Z），便于溯源
• 脚本自身记录调用日志（含时间、用户名、返回状态、公钥指纹 SHA256），日志路径需独立且不可被普通用户写入
• SELinux 环境下，给脚本打上 ssh_exec_t 类型标签；若用 systemd-run 启动子进程，需加 --scope 参数隔离资源
• 严禁多个用户共用同一份 authorized_keys 文件；每个用户必须走独立查询路径，实现天然隔离

常见故障排查方向

报错 Authentication refused: bad ownership or modes for directory 往往不是权限问题，而是 AuthorizedKeysCommand 返回空或格式非法。

• 手动模拟执行：sudo -u ssh-keymgr /usr/libexec/openssh/ssh-get-keys alice，检查输出是否合规
• 查看 /var/log/secure 或 journal 日志，搜索 AuthorizedKeysCommand 关键字，确认是否因权限、超时或 SELinux 拒绝而退出
• 临时把命令设为 /bin/echo "ssh-rsa AAA..." 验证基础链路是否通，再逐步替换为真实逻辑