不能用 chattr +i 锁定 ~/.ssh/authorized_keys 文件——这会彻底禁止所有写入（包括 root），导致 SSH 登录失败、自动化部署中断；应改用 chattr +a 配合目录 700 权限实现安全追加。
直接结论：不能用 chattr +i 锁定 ~/.ssh/authorized_keys 文件来“防止非法添加公钥”——这会同时阻止合法的 SSH 公钥更新，导致用户无法登录。
为什么 chattr +i 不适合保护 authorized_keys
因为 i（immutable）属性会让文件彻底不可修改、不可删除、不可重命名，连 root 也无法写入或追加内容。而 authorized_keys 是一个需要动态维护的文件：运维添加新密钥、自动化脚本更新、CI/CD 注入部署密钥、甚至用户自己通过 ssh-copy-id 添加公钥，都依赖对该文件的写权限。
一旦执行：
chattr +i ~/.ssh/authorized_keys
后续任何写操作都会失败，报错：
Permission denied（即使你是 root，且文件权限是 600）
常见误操作后果包括：
- SSH 登录失败（
sshd读取失败或跳过该文件） -
ssh-copy-id报Could not append to authorized_keys - Ansible 或 Puppet 部署密钥任务静默失败
- 手动
echo ... >> authorized_keys直接被内核拒绝
真正有效的替代方案：用 chattr +a + 严格目录权限
如果你的核心诉求是「只允许追加、禁止覆盖或清空」，a（append-only）才是更合理的选择——它允许向文件末尾写入（如追加新公钥），但禁止截断、重写、删除已有行。
实操步骤：
- 确保
~/.ssh目录权限为700：chmod 700 ~/.ssh - 设置
authorized_keys为追加模式：chattr +a ~/.ssh/authorized_keys - 确认生效：
lsattr ~/.ssh/authorized_keys应显示----a-------e---
注意点：
-
+a对目录也有效：设在~/.ssh上时，只允许在该目录下创建/修改文件，但不允许删除——这对防止恶意替换整个authorized_keys文件也有辅助作用 -
+a不阻止rm authorized_keys && touch authorized_keys这类绕过行为，所以必须配合~/.ssh目录的700权限和属主控制 - 某些旧内核（a 属性，建议先验证：
chattr +a /tmp/test && echo x >> /tmp/test
更健壮的做法：结合 flock + 权限最小化
如果系统频繁由多个脚本或服务更新 authorized_keys（比如 CI 推送密钥），光靠 chattr 不足以避免竞态写入。此时应引入显式锁机制：
示例 Bash 片段（安全追加公钥）：
exec 200>>"$HOME/.ssh/authorized_keys"
flock -n 200 || { echo "locked"; exit 1; }
echo "$NEW_KEY" >>"$HOME/.ssh/authorized_keys"
flock -u 200
关键点：
- 使用
flock文件描述符锁，避免多进程并发写乱序 - 仍需保证
authorized_keys文件本身可写（即不能设+i） - 推荐把该逻辑封装成独立脚本，并限制执行者为特定管理组（如
ssh-admins）
最后提醒：最常被忽略的是 ~/.ssh 目录的属主和权限。哪怕 authorized_keys 被锁死，只要攻击者能写入 ~/.ssh 目录，就能替换整个文件——所以 chown $USER:$USER ~/.ssh && chmod 700 ~/.ssh 比单独锁文件更重要。
