☰

如何在 ssh 救援模式下使用 chroot 修复损坏的服务器（升级后）

tag-icon • tag-icon ssh debian chroot troubleshooting
如何在 ssh 救援模式下使用 chroot 修复损坏的服务器（升级后）

首先，我并非想创建 ssh-jail。

情况如下

我决定将我的服务器从 Debian 9 升级到 12。但现在我被锁定了。

我一步步进行：从 9 到 10，从 10 到 11，从 11 到 12，每次都遵循相同的过程：

  • 更改存储库/etc/apt/sources.list
  • apt update
  • apt upgrade
  • apt full-upgrade
  • 重启

一切顺利，除了最后一次重启（在 Debian 12 中）后，当我尝试在服务器上进行 ssh 时，出现了“连接被拒绝”的情况。我用 进行了检查nmap，发现端口 22 不再打开...

我无法物理访问服务器，只能通过 ssh 访问。

到目前为止我尝试过的

我能够在救援模式下重新启动，并通过 ssh 登录救援操作系统（Debian 10）。

我能够挂载损坏系统的根文件系统。我开始查看配置文件，但找不到任何表明sshd已禁用的东西。

我的下一个想法是在损坏的文件系统中进行 chroot 并尝试解决我的问题：启用 sshd 或检查某些 iptables 规则（与 Debian 12 一起安装？）是否关闭了端口 22。

问题是，我从来没有使用过 chroot，而且我对 iptables 也不是很熟悉。

我从中找到了灵感https://wiki.debian.org/chroot：

mount /dev/md3 /mnt/server            # that's obviously the root filesystem of my server
mount --bind /sys /mnt/server/sys
mount --bind /dev /mnt/server/dev
mount --bind /dev/pts /mnt/server/dev/pts
mount --bind /proc /mnt/server/proc
mount --bind /run /mnt/server/run     # maybe this was not a good idea
chroot /mnt/server

我注意到我的提示发生了变化，因此我认为我的用户的.bashrc文件已被获取，并且我尝试启用sshd它systemctl，但收到一条错误消息：
Failed to enable unit, refusing to operate on linked unit file sshd.service.

然后我花了一些时间阅读（RTFM，他们说......）并且我的 ssh 连接超时了。

当我重新登录时，我处于救援操作系统（/是救援操作系统根目录，并且我的服务器根文件系统仍安装在/mnt/server）。因此，我假设 chroot 随 ssh 会话一起终止（这是正确的吗？）但是，我无法umount：

umount /mnt/server/sys                    # ok
umount /mnt/server/dev                    # ok
umount /mnt/server/dev/pts                # ok
umount /mnt/server/proc                   # ok
umount /mnt/server/run                    # not ok
umount: /mnt/server/run: target is busy.
umount /mnt/server                        # not ok
umount: /mnt/server: target is busy.

我试过了umount -f，得到的答复相同。看来我在 chroot 的进出过程中卡住了...

lsof /mnt/server/run显示了很多似乎与系统密切相关的进程列表，所以我不确定将它们全部杀死是否安全......

COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd       1 root   66u  FIFO   0,21      0t0   72 /run/initctl
systemd       1 root   70u  FIFO   0,21      0t0   47 /run/dmeventd-server
systemd       1 root   71u  FIFO   0,21      0t0   48 /run/dmeventd-client
systemd-j   333 root  mem    REG   0,21  1310720 1988 /run/log/journal/27246933cf104042b7aae4c021b5e14e/system.journal
systemd-j   333 root  mem    REG   0,21  1310720 1987 /run/log/journal/27246933cf104042b7aae4c021b5e14e/system@8b38c633380f402087964636cbfb1666-000000000000a96c-00060ac0e0953243.journal
systemd-j   333 root  mem    REG   0,21        8   78 /run/systemd/journal/kernel-seqnum
systemd-j   333 root   15u   REG   0,21  1310720 1987 /run/log/journal/27246933cf104042b7aae4c021b5e14e/system@8b38c633380f402087964636cbfb1666-000000000000a96c-00060ac0e0953243.journal
systemd-j   333 root   21u   REG   0,21  1310720 1988 /run/log/journal/27246933cf104042b7aae4c021b5e14e/system.journal
systemd-l   557 root   10r  FIFO   0,21      0t0 1609 /run/systemd/sessions/c1.ref
systemd-l   557 root   16r  FIFO   0,21      0t0 1900 /run/systemd/sessions/c6.ref
systemd-l   557 root   17r  FIFO   0,21      0t0 1911 /run/systemd/sessions/c7.ref
systemd-l   557 root   18r  FIFO   0,21      0t0 1993 /run/systemd/sessions/c10.ref
systemd-l   557 root   19r  FIFO   0,21      0t0 1969 /run/systemd/sessions/c9.ref
cron        558 root    3uW  REG   0,21        4 1571 /run/crond.pid
su          714 root    6w  FIFO   0,21      0t0 1609 /run/systemd/sessions/c1.ref
sshd       6314 root    8w  FIFO   0,21      0t0 1993 /run/systemd/sessions/c10.ref
sshd      17335 root    8w  FIFO   0,21      0t0 1900 /run/systemd/sessions/c6.ref
sshd      21595 root    8w  FIFO   0,21      0t0 1969 /run/systemd/sessions/c9.ref
sshd      29605 root    8w  FIFO   0,21      0t0 1911 /run/systemd/sessions/c7.ref

以下是我目前的问题：

  • 假设 chroot 随着 ssh 会话的结束而终止，这样正确吗？
  • 如果不是，那么我在矩阵中的什么位置？
  • 在 chrooted 环境中mount bind /sys、/dev、/dev/pts、/proc和是否必要/安全？/run
  • 如果我要使用screen，我可以在一个窗口中运行 chroot 并在另一个窗口中保留救援操作系统根目录吗？
  • 我认为 chroot 和 mount 都不会在重启后继续存在，是吗？（我随时都会发现，因为这是我的下一步……）

（我会一路编辑问题来表明我的进度并真正找到主要问题）

答案1

我会使用 live cd 启动，然后挂载损坏系统的根分区。例如mount /dev/sdXY /mnt，然后chroot /mnt 刷新所有 iptables 规则iptables -F。然后退出 chroot 并卸载根分区。

对于ssh，Debian中的ssh服务不叫sshd，而是叫ssh。

  1. 再次挂载根分区并挂载一些额外的重要目录。
    mount --bind /dev /mnt/dev

    mount --bind /proc /mnt/proc

    mount --bind /sys /mnt/sys

  2. 再次进入 chrootchroot /mnt并检查 ssh 服务的状态systemctl status ssh。还要确保 openssh-server 已安装，如果未安装，请运行 apt-get install openssh-server。您也可以尝试使用以下命令启用它systemctl enable ssh

  3. 如果你的 ssh 配置损坏，你可能需要使用以下方法重置它： mv /etc/ssh/sshd_config /etc/ssh/sshd_config.bak dpkg-reconfigure openssh-server

  4. 完成后退出 chroot，并卸载所有内容。

    umount /mnt/dev

    umount /mnt/proc

    umount /mnt/sys

    umount /mnt

  5. 然后重启

相关内容