☰

在隔离的 rescue.target 中启动 SSH？

tag-icon • tag-icon boot ssh systemd rescue-mode
在隔离的 rescue.target 中启动 SSH？

我计划在一台只有 SSH 访问权限的远程机器上将系统从 Eoan 升级到 Focal。我之前处理过损坏的软件包导致系统启动到救援模式，所以我想确保无论发生什么情况我都能保持对服务器的访问权限。为了进一步确保该过程的安全，我正在使用运行目标系统的本地虚拟机进行演练。

凭借我对 Ubuntu 的了解，我事先做了以下任务：

  • systemctl edit ssh.service并插入DefaultDependencies=no到 [Unit] 部分和WantedBy=rescue.target[Install] 部分，然后systemctl enable ssh.service。Systemd 报告“创建了符号链接”。
  • systemctl edit rescue-ssh.target并插入WantedBy=rescue.target到[安装]部分，然后systemctl enable rescue-ssh.target。

然后我编辑 grub 以启用启动菜单，update-grub然后systemctl reboot，并使用e编辑默认条目。我向下滚动到第一linux行，并使用 Ctrl-X 附加rescue并启动此条目，然后出现此屏幕：

救援模式

这里一切似乎都很好，因为我此时就可以通过 SSH 进入该 VM。

我的问题是：

我再次尝试以不同的方式测试救援模式下的 SSH 可用性。首先，我正常启动系统进入图形模式（使用 GNOME 等），启动终端并运行systemctl isolate rescue.target。我再次看到相同的提示文本，但当我尝试通过 SSH 进入虚拟机时，我得到了以下结果：

ubuntu@WSL:~ $ ssh root@vmwares
Warning: Permanently added '192.168.2.5' (ECDSA) to the list of known hosts.
Timeout, server 192.168.2.5 not responding.
255|ubuntu@WSL:~ $

运行systemctl status ssh.service突出显示以下文本：

pam_systemd（sshd：session）：无法创建会话：无法激活服务“org.freedesktop.login1”：超时（service_start_timeout=25000ms）

重启systemd-logind.service没什么区别。返回图形界面可以systemctl isolate default.target让一切恢复正常。

问题：当救援目标与 graphic.target 隔离时，为什么我无法登录 SSH？我该如何解决这个问题？

我认为这与“隔离目标”有关，但显然事情已经超出了我的知识范围。

相关内容