authorizedkeysfile 是 ssh 服务端指定公钥存放路径的配置项，核心作用是打破默认路径依赖、增强安全性；需在 /etc/ssh/sshd_config 中配置非标准路径（如 /etc/ssh/keys/%u/authorized_keys），配合严格权限、禁用密码登录及密钥限制选项方可有效加固。
AuthorizedKeysFile 不是用来“开启免密登录”的开关，而是告诉 sshd 去哪里找用户的公钥。规范化路径的核心目标是：统一管理、权限可控、规避默认路径暴露风险。关键不在“改不改”，而在“怎么改得稳、管得住”。
明确路径语义与推荐写法
AuthorizedKeysFile 支持相对路径（相对于用户主目录）和绝对路径，但必须兼顾可扩展性与安全性：
- 推荐用带 %u 的绝对路径：如 /etc/ssh/keys/%u/authorized_keys。%u 自动替换为用户名，避免所有用户共用一个文件，也防止跨用户误读
- 不建议只写 .ssh/authorized_keys —— 这是默认值，等于没加固；也不建议写死单个绝对路径（如 /etc/ssh/keys/alice/authorized_keys），无法复用到新用户
- 支持多路径（空格分隔），但生产环境建议只设一个主路径，降低排查复杂度
目录与文件权限必须严格匹配
sshd 在读取 authorized_keys 前会做两级权限校验：父目录不能被组/其他用户写入；文件本身不能被组/其他用户修改。任意一项不满足，就会静默拒绝该密钥。
- 目录权限（如 /etc/ssh/keys/alice）：750，属主 root，属组为该用户（如 alice），确保只有 root 可写、用户可读
- authorized_keys 文件权限：644（不是 600）。因为 sshd 以 root 身份运行，需保证组（即用户所属组）有读权限；若设为 600，且 umask 或 OpenSSH 版本较新，可能因组无读权而跳过加载
- 切勿对 /etc/ssh/keys 根目录设 755 或开放写权限——这是常见提权入口
配套配置缺一不可
只改 AuthorizedKeysFile 路径，却不收紧其他环节，等同于给门换了锁，却忘了关窗户。
- 确认启用公钥认证：PubkeyAuthentication yes，同时关闭密码登录：PasswordAuthentication no
- 禁用默认路径继承：检查是否有 Match User 或 Include 引入的子配置意外覆盖了 AuthorizedKeysFile，可在全局段显式声明一次，避免被覆盖
- 在 authorized_keys 每行公钥前加限制项，例如：
no-port-forwarding,no-X11-forwarding,command="/bin/false" ssh-ed25519 AAAA...
这能阻止攻击者利用已植入密钥执行命令或端口转发
验证与生效流程要闭环
改完不验证，等于白改。操作后务必走完以下步骤：
- 语法检查：sudo sshd -t —— 返回 success 才继续
- 重启服务：sudo systemctl restart sshd（注意不要用 reload，部分旧版本不重载 AuthorizedKeysFile）
- 用非当前终端新起连接测试，避免锁死；失败时看 journalctl -u sshd -n 50 -f 查具体拒绝原因（常见如 permissions wrong、bad ownership）
- 确认新路径下公钥内容格式正确：一行一条，无多余空格或换行，末尾无注释
