不推荐直接对 ~/.ssh/authorized_keys 使用 chattr +i，因其会阻止 openssh 写入导致密钥认证失效；应严格遵循权限700/600、属主正确及目录锁定三重控制。
chattr +i 对 ~/.ssh/authorized_keys 为什么通常不推荐
直接给 ~/.ssh/authorized_keys 加 chattr +i 会导致 SSH 公钥认证完全失效——OpenSSH 在每次登录时会尝试检查并（在某些配置下）写入或更新该文件，chattr +i 会让内核拒绝所有写操作，包括追加、截断、重命名，甚至 chmod 和 chown 都会失败。常见现象是：用户能输密码登录，但密钥登录直接被拒绝，且 sshd -T 或 journalctl -u ssh 中出现类似 Authentication refused: bad ownership or modes 或更隐晦的 Could not open authorized keys file 错误。
真正安全的替代方案：用权限+属主+目录锁三重控制
OpenSSH 官方文档明确要求：~/.ssh 目录权限必须是 700，authorized_keys 文件权限必须是 600，且属主必须为对应用户（不能是 root）。只要满足这三点，普通用户进程无法篡改该文件；而 chattr +i 属于过度防御，反而破坏 SSH 自身行为逻辑。实际加固应聚焦于此：
-
chmod 700 ~/.ssh和chmod 600 ~/.ssh/authorized_keys -
chown $USER:$USER ~/.ssh ~/.ssh/authorized_keys（确保不是 root 或其他用户） - 对整个
~/.ssh目录加chattr +i？不行——sshd 进程需要创建known_hosts、authorized_keys2（旧版）等文件，会报错 - 若真要防 root 级篡改（如多管理员环境），应靠审计（
aureport -m -f ~/.ssh/authorized_keys）和最小权限原则，而非文件锁
极少数需锁定的场景：只读镜像或离线密钥分发
仅当 authorized_keys 是只读系统的一部分（如嵌入式设备固件、Docker 构建阶段生成后不再变更），且你**完全控制 SSH 服务启动方式**（例如用 sshd -o AuthorizedKeysCommand=... 替代文件读取），才可考虑 chattr +i。此时务必确认：
- sshd 配置中未启用
AuthorizedKeysFile的通配符（如%h/.ssh/authorized_keys2），否则仍可能绕过 - 系统使用的是 ext4/xfs 等支持
chattr的文件系统（btrfs/zfs 不支持i标志） - 执行前已退出所有 SSH 会话，并用
sudo chattr +i ~/.ssh/authorized_keys（普通用户无权设置i） - 后续任何密钥更新都必须先
sudo chattr -i，改完再加回——这本质上放弃了自动化运维
检查是否生效及常见误操作
运行 lsattr ~/.ssh/authorized_keys 应输出类似 ----i---------e---（i 在第 5 位）。但要注意：
- 如果看到
lsattr: Permission denied，说明当前用户无权读取扩展属性，不是锁没加成，而是权限不足 - 加了
i后，连sudo echo "key" >> ~/.ssh/authorized_keys都会失败，报Operation not permitted -
chattr +i对符号链接本身无效，只对目标文件起作用；如果authorized_keys是软链，需对真实文件操作 - 容器或 systemd --user 环境中，
~可能指向非预期路径（如/var/lib/sss/mc），务必用绝对路径确认
最常被忽略的一点：SSH 强制校验文件权限和属主，但不校验 chattr 状态——所以加了 i 不等于更安全，只是让错误更难排查。
