救援模式不能是免密后门
在 systemd 体系里，单用户与救援目标由 rescue.service 与 emergency.service 承载。若其中没有 sulogin 环节，任何能接触控制台或带外管理的人都能拿到 root shell，文件权限做得再严也没意义。sulogin 的作用就是在这条路径上要求输入 root 口令。
基本信息
| 适用平台 | Linux（systemd 体系发行版） |
|---|---|
| 相关单元 | rescue.service、emergency.service |
| 验证方式 | 带外控制台实测，或查看单元内容确认含 sulogin |
| 基线 | 救援与紧急模式均要求 root 口令 |
典型使用场景
- 物理接触风险高的机房：控制台与键盘是唯一物理入口，必须设防
- 合规检查：引导与单用户模式防护属于经典检查项
- 故障演练：验证出现系统故障时，运维仍能凭口令进入救援模式
- 云主机：确认平台控制台的功能与本地救援路径的差别
核查
核查
# 查看两个单元的执行内容中是否含 sulogin
systemctl cat rescue.service emergency.service 2>/dev/null | grep -i sulogin
# 确认 root 口令存在且可用（不要在生产上直接改）
passwd -S root
# 带外控制台实测：内核命令行追加 single 或 systemd.unit=rescue.target
# 正常应被要求输入 root 口令，而不是直接进入 shell检查项读法
| 检查项 | 正常表现 | 异常表现 |
|---|---|---|
| rescue.service | 执行内容包含 sulogin | 无 sulogin 时控制台可直接进入 shell |
| emergency.service | 同样包含 sulogin | 仅保护其一，另一条路径仍可绕过 |
| GRUB 口令 | 已设置 | 无口令时可加 init=/bin/bash 绕过 sulogin |
| root 口令 | 已托管且有记录 | 口令遗失时救援模式反而进不去 |
sulogin 依赖 root 的 shadow 口令：务必把 root 口令与带外通道一起托管，否则可能把自己锁在救援模式之外，只能靠重装或物理拆盘恢复。
GRUB 无口令时攻击者可加 init=/bin/bash 绕过 sulogin：引导口令与救援模式认证必须配套，只做一项防护等于没做。
云主机与传统硬件的救援路径不同：云上多依赖平台控制台，验证方式要结合平台能力设计，不能直接把物理机流程照搬过来。