这事会发生。这里不做评判。你创建了一个 32 个字符、塞满特殊字符的密码，而且你 以为 自己已经在密码管理器里记了一笔，但不知怎么的，你并没有。你没有配置 sudo 或 doas，而现在你需要以 root 身份做某件事，却做不了。
哦不！
但并非全无希望。至少有两种方法可以解决这个问题。
使用你的面板
首先要检查的是服务商的面板是否支持重置 root 密码。简直就像托管公司收到太多重置 root 密码的请求，以至于托管面板提供商把它内置进去，好让自己少些头疼……嗯。
我登录了 RackNerd 上的 Solus，我看到的是：
那我们就试试这个。
点击更改后，你会看到这条消息：
然后在点击“是”之后：
（别担心——我会在这篇文章发布前把它改掉！）
经过短暂处理，它成功了：
现在在我的情况下，只有一个问题。作为我 VPS 设置的一部分，我的 Ansible 脚本把这放进了 /etc/ssh/sshd_config：
所以实际上我无法以 root 登录。在这个特定情况下，丢失 root 密码其实无关紧要，因为我可以使用我的 ssh key 登录，但你明白意思。如果我丢了 ssh key，我就完蛋了。
使用 Rescue
让我们看看 SolusVM 的 Rescue 模式：
点击它会给出一个警告：
我点击了“Enable Rescue Mode”，SolusVM 礼貌地要求我确认：
是的，请。
点击 Yes 之后：
我让它启动了一会儿，然后就能从我的 PC 登录了：
哇……那些 -o 标志是怎么回事？如果你不使用它们，就会收到那个戏剧性的警告：“有可能有人正在做一些恶意的事情！”
原因是，这个 IP 在我的 hosts 文件中与某个主机密钥关联，而当我以救援模式启动时，它完全是不同的 OS 镜像。所以我的 ssh 客户端会得到完全不同的主机密钥并报错。我列出的 -o 标志会临时忽略这一点，而无需进入并修改 known_hosts 文件。
现在登录后，需要注意的是，我并不是直接登录到我的 VPS 本身。我登录的是一个救援镜像。例如：
如果我现在运行 passwd root，我改的是救援镜像的密码，这毫无意义。
所以我们还有一点工作要做。首先，找到你 VPS 实际的根分区：
OK，那么救援环境是 /dev/vdb1。/dev/vda1 是我实际的根分区。所以我们为它准备一个 chroot 环境。
然后进入 chroot 环境：
现在我已在我的实际 VPS 中。例如：
现在我可以重置 root 密码了：