一条 chown 命令，直接锁死云服务器

上周搞了一次事故，原因蠢到我不想承认。

环境是 OCI（甲骨文云），CentOS 7.9，SSH Key 登录，默认用户 opc。算是很常见的配置。

当时在/home目录下，想改一个目录的归属，顺手敲了：

chownaxon:axon opc

执行完，SSH 断了。再连，Permission denied (publickey)。

懵了一下，以为是网络问题，重连，还是不行。打开 OCI 控制台试 Console Connection，也进不去。这才意识到，是真锁死了。

为什么会这样

SSH 登录有一套挺严格的权限要求，稍微不对就直接拒。具体来说：

• /home/opc这个目录，必须属于opc用户
• .ssh目录权限必须是 700
• authorized_keys文件权限必须是 600

我那条命令把/home/opc的归属改成了axon:axon，SSH 一检查，信任链断了，直接拒连，连密钥都不让你出示。

这就是为什么换密钥、改安全组、重启都没用——问题根本不在"连接"这一层，是"信任"这一层就已经拒掉了。

常规手段为什么全失效

我一开始的反应跟大多数人一样：

1. 重启实例 → 没用
2. 检查安全组 → 没用
3. 想换个 SSH Key → 进不去改不了
4. Console Connection → 也进不去（同样依赖 opc 用户的权限环境）

绕了一圈发现，只要系统还活着，所有登录路径都得过权限这关。

真正有效的思路：直接修磁盘

既然登不进去，那就不登了。

OCI 支持把实例的 Boot Volume 分离出来，挂到另一台正常的实例上当数据盘用。这样就完全绕开了 OS 层，直接在文件系统层面改文件——权限问题不就只是改几个文件属性嘛。

整个救援流程如下。

OCI 控制台操作

第一步：停止故障实例

Compute → Instances → 选中故障机 → Stop，等它彻底停下来。

第二步：分离 Boot Volume

进入实例详情，找到 Boot Volume 那一栏，点进去，Detach。等状态变成 Available。

第三步：挂到救援机

找一台能正常登录的实例，进详情页，Attach Boot Volume，选刚才分离的那块盘。

参数：

• Attach type：Paravirtualized
• Access：Read/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

如果系统开了 SELinux（CentOS 默认开），还得修一下安全上下文，不然改完权限还是进不去：

restorecon-Rv/mnt/rescue/home/opc

卸载：

umount/mnt/rescue

把磁盘还回去

在救援机上 Detach

OCI 控制台 → 救援机实例 → 找到 Attached Boot Volume → Detach。

Attach 回原实例

回到原来的故障实例，Attach Boot Volume，选择这块盘，确认它作为 Boot Volume。

启动

Start 实例，等它起来，重新 SSH：

sshopc@<ip>

进去了。

事后想了一下

这次事故说起来其实挺低级的，但有几点值得记一下：

SSH 是信任系统，不是连接系统。很多人（包括我）直觉上觉得 SSH 出问题就是网络问题，但权限问题导致的 SSH 拒连跟网络根本没关系——网络没问题，但被拒了。

chown -R 在 /home 下是高风险操作。不是说不能用，是要特别确认路径。漏个/或者多个层级，就是这次的结果。

OCI 的 Detach/Attach 机制很好用。其实 AWS、Azure 这些也有类似操作，下次遇到系统级的麻烦可以第一时间往这个方向想，不用在登录上死磕。

最后，最简单的自救方式：

pwd

执行高风险命令之前先确认自己在哪，两秒钟的事。