当Linux实例中关键的系统用户不存在时，可能导致无法远程登录。您可以通过实例健康诊断工具进行问题修复。

前提条件

Linux实例已通过实例健康诊断工具进行诊断，诊断结果中实例无法启动场景的根账号检查未通过。

背景信息

问题描述：在Linux操作系统中，/etc/passwd文件存储了系统所有用户的基本信息，/etc/shadow文件存储了系统用户的密码信息。如果文件中关键的系统用户信息（例如root用户及密码）丢失，将导致无法正常登录该实例。

解决方案：您需要恢复/etc/passwd和/etc/shadow配置文件的信息。此外，/etc/group文件中存放了系统用户组的基本信息以及用户与用户组之间的关系信息，也需要一同修复。

操作步骤

  1. 准备正确的系统用户信息配置文件。

    由于不同的Linux发行版中关键的系统用户有所不同，且您在使用过程中可能创建了其它系统用户，因此修复系统关键用户信息丢失的问题需要您根据不同的Linux发行版而定。

    建议您通过一台正常运行的ECS实例获取正确的系统用户配置文件信息，作为修复问题实例的参考文件。正常运行的ECS实例需要和问题实例使用同一Linux发行版本，并且安装了相同的软件包。所需正确的系统用户配置文件信息的路径如下所示：

    • /etc/passwd
    • /etc/shadow
    • /etc/group
    您可以直接在正常运行的ECS实例内查看正确的配置文件信息，也可以将正确的配置文件信息下载至本地主机进行查看。本文以CentOS 7.5系统为例，配置文件的内容示例如下：
    • /etc/passwd
      root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
polkitd:x:999:998:User for polkitd:/:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
postfix:x:89:89::/var/spool/postfix:/sbin/nologin
chrony:x:998:996::/var/lib/chrony:/sbin/nologin
ntp:x:38:38::/etc/ntp:/sbin/nologin
tcpdump:x:72:72::/:/sbin/nologin
nscd:x:28:28:NSCD Daemon:/:/sbin/nologin
    • /etc/shadow
      root:$6$Q9lA****/t1KPM$JLqO59UTxwGm****/rU7bHL0q5TVAij****/KeWAWPiO.6booVwpp7rdR9****.irQ6nso3YGVSqQqpyT****.:18668:0:99999:7:::
bin:*:17632:0:99999:7:::
daemon:*:17632:0:99999:7:::
adm:*:17632:0:99999:7:::
lp:*:17632:0:99999:7:::
sync:*:17632:0:99999:7:::
shutdown:*:17632:0:99999:7:::
halt:*:17632:0:99999:7:::
mail:*:17632:0:99999:7:::
operator:*:17632:0:99999:7:::
games:*:17632:0:99999:7:::
ftp:*:17632:0:99999:7:::
nobody:*:17632:0:99999:7:::
systemd-network:!!:17864::::::
dbus:!!:17864::::::
polkitd:!!:17864::::::
sshd:!!:17864::::::
postfix:!!:17864::::::
chrony:!!:17864::::::
ntp:!!:17864::::::
tcpdump:!!:17864::::::
nscd:!!:17864::::::
    • /etc/group
      root:x:0:
bin:x:1:
daemon:x:2:
sys:x:3:
adm:x:4:
tty:x:5:
disk:x:6:
lp:x:7:
mem:x:8:
kmem:x:9:
wheel:x:10:
cdrom:x:11:
mail:x:12:postfix
man:x:15:
dialout:x:18:
floppy:x:19:
games:x:20:
tape:x:33:
video:x:39:
ftp:x:50:
lock:x:54:
audio:x:63:
nobody:x:99:
users:x:100:
utmp:x:22:
utempter:x:35:
input:x:999:
systemd-journal:x:190:
systemd-network:x:192:
dbus:x:81:
polkitd:x:998:
ssh_keys:x:997:
sshd:x:74:
postdrop:x:90:
postfix:x:89:
chrony:x:996:
ntp:x:38:
tcpdump:x:72:
nscd:x:28:
  2. 远程连接问题实例。
    当ECS实例处于正在挂载修复盘的模式下时，只能通过VNC远程连接。具体操作，请参见使用VNC登录实例。
  3. 查看问题实例原有系统盘的挂载信息。
    在临时挂载的修复盘中，问题实例原有系统盘的文件系统会被挂载到某一临时目录下。您可以通过以下任一方式查看所在的临时目录信息：
    • 在系统盘详情页的挂载实例进行查看，对应的临时目录格式示例为：/tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****，其中bp19bspzms79kqse****为实例原有系统盘的云盘序列号。
    • 在临时挂载的修复盘中，运行mount命令查看。例如，问题实例原有系统盘的设备路径为/dev/vda，命令示例如下所示：
      mount | grep /dev/vda
      返回结果如下所示：
      /dev/vda1 on /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse**** type ext4 (rw,relatime)
  4. 运行chroot命令，将根目录切换为问题实例原有系统盘所在的临时路径，并进入chroot环境。
    您需要在问题实例原有系统盘所在的临时路径中进行文件修复。例如，临时路径为/tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****，命令如下所示：
    chroot /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****
  5. 在chroot环境中，运行以下命令，备份/etc/passwd与/etc/shadow原文件。
    cp /etc/passwd /etc/passwd.bak
cp /etc/shadow /etc/shadow.bak
  6. 补充/etc/passwd文件缺失的信息。
    1. 通过ECS控制台的实例健康诊断结果，获取缺失的系统关键用户的信息。
    2. 在已准备好的正确的系统用户信息配置文件/etc/passwd中，找到对应的系统关键用户信息，然后复制所在行的内容。
    3. 将内容粘贴到chroot环境的/etc/passwd文件中对应缺失的位置。
      说明 修复状态的ECS实例只能通过VNC远程连接，当您需要输入复制的内容时，单击顶部的VNC复制命令输入按钮。
      /etc/passwd文件中格式说明如下所示。
      一行用户信息的示例内容如下所示：
      postfix:x:89:89::/var/spool/postfix:/sbin/nologin
      每一行用户信息被冒号（:）分隔为7个字段，每个字段对应的说明如下：
      用户名:密码:uid:gid:用户描述:主目录:登录shell
      粘贴后，您需要对新增的用户信息进行检查：
      • 新增用户信息中的uid不能与文件中其他用户的uid重复。
      • 新增用户信息中的gid必须存在于chroot环境的/etc/group文件中。如果不存在，需要复制正确的/etc/group文件中对应的gid所在行到chroot环境的/etc/group中，并确保新增内容的gid不能与文件中其它的gid重复。
        例如：
        • chroot环境的/etc/group文件中存在对应的gid为89，则已满足要求，无需对/etc/group文件进行改动。
        • chroot环境的/etc/group文件中不存在对应的gid为89，则需要复制正确的/etc/group文件中对应的gid所在行到chroot环境的/etc/group中，且不能与其它行的gid重复。
      • 新增用户信息如果在正确的/etc/group文件中存在用户和用户组的关联关系，则在chroot环境的/etc/group文件中也需要保持一致的关联关系。

        例如：chroot环境中的/etc/passwd文件中缺失了postfix用户，除了需要复制正确的/etc/passwd和/etc/group文件中的配置项，如果正确的/etc/group文件中配置了postfix用户同时属于mail组（例如mail:x:12:postfix），则需要将该配置项复制到chroot环境的/etc/group文件中。

  7. 补充/etc/shadow文件缺失的信息。
    1. 通过ECS控制台的实例健康诊断结果，获取缺失的系统关键用户的信息。
    2. 在已准备好的正确的系统用户的密码信息配置文件/etc/shadow中，找到对应的系统关键用户信息，然后复制所在行的内容。
    3. 将内容粘贴到chroot环境的/etc/shadow文件中对应缺失的位置。
      说明 修复状态的ECS实例只能通过VNC远程连接，当您需要输入复制的内容时，单击顶部的VNC复制命令输入按钮。
      如果chroot环境的/etc/shadow文件中信息未缺失，则不需要粘贴。
  8. 修复完成后，退出修复环境，然后检查问题实例的当前状态。
    1. 运行exit命令，退出chroot环境。
    2. 在ECS控制台的实例健康诊断页面，卸载临时挂载的修复盘并恢复问题实例至正常模式。
    3. 远程连接已修复的ECS实例，确认成功登录。

其他解决方案

在正常实例上挂载异常实例的系统盘进行修复的具体操作，请参见Linux实例中关键的系统用户不存在。