Answer Password Prompts with systemd-tty-ask-password-agent

A boot hangs on a disk passphrase nobody can see, and systemd-tty-ask-password-agent is the tool that surfaces the prompt so you can answer it. This is useful for prompts such as an encrypted disk passphrase or a certificate password that must be supplied while a system operation is running. Allow about ten minutes for a simple check.

Answering a real prompt requires access to the machine and knowledge of the secret it is requesting. This guide covers the installed Ubuntu package, systemd 255.4-1ubuntu8.17, whose command reports systemd 255. The local manual page is the authority for the examples below; behaviour and available options can differ on older systemd releases.

1. Confirm the installed command

Run the version check as your ordinary user. It does not change the system and does not need sudo:

$ systemd-tty-ask-password-agent --version
systemd 255 (255.4-1ubuntu8.17)

The package version in the example is specific to this machine. If yours differs, read the installed manual page before copying options into a script:

$ man systemd-tty-ask-password-agent

2. List pending requests without answering them

Start with --list. It reports all currently pending system password requests and does not ask for a secret:

$ systemd-tty-ask-password-agent --list

When there are no requests, successful output is empty. On the machine used for this guide, the command returned status 0 and printed nothing. An empty result means there is nothing for this agent to display at that moment; it does not prove an operation has finished, that encryption is disabled, or that another user-facing agent is not active.

Check the exit status when using the command in a script:

$ systemd-tty-ask-password-agent --list
$ printf 'agent status: %s\n' "$?"
agent status: 0

Do not parse an empty line as a password request. Requests can disappear because they expire, are cancelled, or are answered by another agent.

3. Answer current requests on your TTY

Use --query to process all requests pending when the command starts. It asks on the calling TTY:

$ systemd-tty-ask-password-agent --query

A successful exit status means the agent completed its work without reporting a failure. It is not proof the secret was correct or that the original service reached its next state. Verify the operation separately, for example with the service's own status command:

$ systemd-tty-ask-password-agent --query
$ printf 'agent status: %s\n' "$?"
agent status: 0
$ systemctl status NAME.service --no-pager

Replace NAME.service with the unit you are actually investigating. The final systemctl command may need elevated privileges to show all details, but do not add sudo to the password-agent command just because a prompt mentions a system resource.

4. Keep watching during a maintenance operation

Use --watch when requests may arrive after the command starts:

$ systemd-tty-ask-password-agent --watch

The process keeps handling password requests until it is stopped. Run it in a terminal you can monitor, and use Ctrl-C once the maintenance work is complete. Do not leave a watch process running unattended, or turn it into a permanent service without first deciding who may see and answer prompts.

This mode is easy to mistake for a hung command. A quiet terminal can simply mean no request is pending. In another terminal, list the queue:

$ systemd-tty-ask-password-agent --list

Stop the watcher before closing the terminal. There is no persistent configuration to undo here; terminating the process only stops this agent instance. It does not cancel the underlying operation or remove a disk-encryption requirement.

5. Select a different delivery target

The default target for --query and --watch is the calling TTY. The manual also gives three explicit alternatives:

• --console asks on /dev/console, while --console=/dev/tty1 names a particular TTY device.
• --wall forwards password requests to wall instead of reading a secret on the calling TTY.
• --plymouth asks through Plymouth, when a working Plymouth environment is available.

These are routing choices, not ways to bypass the request. For example, a console agent is useful when the terminal that started a recovery task is not the terminal attached to the machine:

$ systemd-tty-ask-password-agent --console=/dev/console

Common traps

• An empty --list is not proof of nothing happening. First check the exact command and the operation that should have created the request. Do not manufacture a request by editing files under /run/systemd/ask-password: those files and their reply sockets are part of the systemd password-agent protocol, and manually changing them can expose secrets or disrupt the requesting process.
• A silent --query is not necessarily broken. There may be no request, the request may have expired, or another agent may have answered it first. Run --list again and inspect the initiating service. If the request appears only briefly, use --watch in a supervised terminal before repeating the operation.
• A rejected request is a real failure, not a retry prompt. Do not keep guessing passphrases, and do not paste a secret into shell history, a ticket, a chat message or a command-line argument. If you suspect a secret was exposed, follow your organisation's credential-rotation procedure.
• Most checks are unprivileged. A request may still concern a privileged system operation, but the agent's job is to deliver the response through systemd's protocol. Use elevated privileges only for a separate diagnostic command that demonstrably needs them, and inspect the command before running it.