systemd环境下延迟USB加密盘解锁至ssh.service激活后，解决超时及TTY无法输入密码的问题

看起来你已经折腾了好一阵，尝试通过自定义target来延迟加密USB的解锁时机，但卡在了超时和TTY无法输入密码的问题上——尤其是手动重启systemd-ask-password-console.service后就能正常输入，这说明核心问题出在密码询问服务的启动时机和依赖绑定上。我帮你梳理下问题并给出调整方案：

先明确你的核心需求 #

你希望：

• 加密USB盘在系统启动且ssh.service完全激活后再触发解锁
• 解锁密码提示永不超时，直到用户输入
• 控制台TTY能正常接收密码输入，不会出现提示出来却没法打字的情况

当前配置的问题点 #

你现在的finish.target和crypttab配置方向是对的，但有几个关键细节没处理到位：

1. 依赖systemd-ask-password-console.path而非直接依赖服务：这个path单元是用来监听密码请求事件的，但它默认在sysinit.target阶段启动，后期通过target依赖它没法主动拉起密码输入进程
2. multi-user.target的依赖逻辑：直接Requires=multi-user.target会让你的target在多用户阶段启动，但没完全压制getty@tty1.service的启动优先级，导致超时后直接跳转到登录界面
3. 密码输入进程未主动激活：systemd-ask-password-console.service在初始启动阶段结束后就会退出，后期没有主动启动它，导致控制台TTY没绑定密码输入处理进程

调整后的配置方案 #

1. 保持crypttab配置不变 #

你的/etc/crypttab参数已经没问题，确保不会自动解锁、永不超时：

crypt   /dev/disk/by-label/crypt        none    nofail,noauto,timeout=0,x-systemd.device-timeout=0

2. 重写finish.target配置 #

把/etc/systemd/system/finish.target改成下面这样，明确依赖关系并主动拉起密码输入服务：

[Unit]
Description=Mount crypt USB
# 确保ssh服务完全激活后才触发
Requires=ssh.service
# 拉起加密解锁服务和控制台密码输入服务
Wants=systemd-cryptsetup@crypt.service systemd-ask-password-console.service
# 明确在ssh之后、tty1登录界面之前启动
After=ssh.service
Before=getty@tty1.service

[Install]
WantedBy=multi-user.target

3. 重新加载systemd配置并启用target #

执行以下命令让配置生效：

systemctl daemon-reload
systemctl enable finish.target

为什么这样改能解决问题？ #

• 直接依赖systemd-ask-password-console.service，会主动启动systemd-ask-password --watch --console进程，绑定控制台TTY来处理密码输入，就像你手动重启服务后的效果一样
• Requires=ssh.service确保只有当ssh服务完全就绪后，才会触发加密盘的解锁流程，符合你的延迟需求
• Before=getty@tty1.service压制了登录界面的启动时机，避免超时后直接跳转到getty，保证密码提示能一直显示直到输入

额外验证步骤 #

如果还是遇到问题，可以试试：

• 查看systemd-ask-password-console.service状态，确认没有冲突：systemctl status systemd-ask-password-console.service
• 检查加密解锁服务的依赖，确保它没有提前启动：systemctl list-dependencies systemd-cryptsetup@crypt.service
• 如果需要支持远程SSH输入密码，可以在Wants里加上systemd-ask-password-wall.service，这样远程和本地都能收到密码提示

备注：内容来源于stack exchange，提问作者dza