上周搞了一次事故原因蠢到我不想承认。环境是 OCI甲骨文云CentOS 7.9SSH Key 登录默认用户 opc。算是很常见的配置。当时在/home目录下想改一个目录的归属顺手敲了chownaxon:axon opc执行完SSH 断了。再连Permission denied (publickey)。懵了一下以为是网络问题重连还是不行。打开 OCI 控制台试 Console Connection也进不去。这才意识到是真锁死了。为什么会这样SSH 登录有一套挺严格的权限要求稍微不对就直接拒。具体来说/home/opc这个目录必须属于opc用户.ssh目录权限必须是 700authorized_keys文件权限必须是 600我那条命令把/home/opc的归属改成了axon:axonSSH 一检查信任链断了直接拒连连密钥都不让你出示。这就是为什么换密钥、改安全组、重启都没用——问题根本不在连接这一层是信任这一层就已经拒掉了。常规手段为什么全失效我一开始的反应跟大多数人一样重启实例 → 没用检查安全组 → 没用想换个 SSH Key → 进不去改不了Console Connection → 也进不去同样依赖 opc 用户的权限环境绕了一圈发现只要系统还活着所有登录路径都得过权限这关。真正有效的思路直接修磁盘既然登不进去那就不登了。OCI 支持把实例的 Boot Volume 分离出来挂到另一台正常的实例上当数据盘用。这样就完全绕开了 OS 层直接在文件系统层面改文件——权限问题不就只是改几个文件属性嘛。整个救援流程如下。OCI 控制台操作第一步停止故障实例Compute → Instances → 选中故障机 → Stop等它彻底停下来。第二步分离 Boot Volume进入实例详情找到 Boot Volume 那一栏点进去Detach。等状态变成 Available。第三步挂到救援机找一台能正常登录的实例进详情页Attach Boot Volume选刚才分离的那块盘。参数Attach typeParavirtualizedAccessRead/Write第四步登录救援机这时候故障机的系统盘已经作为一块普通数据盘挂进来了接下来在救援机上操作。命令行修复过程登上救援机之后# 确认新盘的设备名一般是 sdblsblk# 确认文件系统类型blkid /dev/sdb3挂载XFS 需要加nouuid不然两块 XFS 卷同时挂会冲突mount-onouuid /dev/sdb3 /mnt/rescue修权限这四条是核心chown-Ropc:opc /mnt/rescue/home/opcchmod755/mnt/rescue/home/opcchmod700/mnt/rescue/home/opc/.sshchmod600/mnt/rescue/home/opc/.ssh/authorized_keys如果系统开了 SELinuxCentOS 默认开还得修一下安全上下文不然改完权限还是进不去restorecon-Rv/mnt/rescue/home/opc卸载umount/mnt/rescue把磁盘还回去在救援机上 DetachOCI 控制台 → 救援机实例 → 找到 Attached Boot Volume → Detach。Attach 回原实例回到原来的故障实例Attach Boot Volume选择这块盘确认它作为 Boot Volume。启动Start 实例等它起来重新 SSHsshopcip进去了。事后想了一下这次事故说起来其实挺低级的但有几点值得记一下SSH 是信任系统不是连接系统。很多人包括我直觉上觉得 SSH 出问题就是网络问题但权限问题导致的 SSH 拒连跟网络根本没关系——网络没问题但被拒了。chown -R 在 /home 下是高风险操作。不是说不能用是要特别确认路径。漏个/或者多个层级就是这次的结果。OCI 的 Detach/Attach 机制很好用。其实 AWS、Azure 这些也有类似操作下次遇到系统级的麻烦可以第一时间往这个方向想不用在登录上死磕。最后最简单的自救方式pwd执行高风险命令之前先确认自己在哪两秒钟的事。