Skip to content

Fix sudo Password Prompts on Raspberry Pi OS Trixie

On current Raspberry Pi OS Trixie images, sudo asks for the password of the logged-in user. A command that used to run unattended can now stop at a password prompt, which is especially visible in headless setup, scripts, Docker bootstrap commands, and desktop administration dialogs.

Quick answer

Enter the password created in Raspberry Pi Imager or change it with passwd, then test access with sudo -v. For a newly installed Trixie image, use sudo raspi-config → System Options → S10 Admin Password if you deliberately want to turn off the prompt. For automation, remove interactive sudo from the job and grant only the exact command it requires through a validated /etc/sudoers.d/ rule.

Raspberry Pi OS 6.2 made an admin-password prompt the default for new Trixie images. Existing installations retain their prior passwordless setting unless it is changed. Raspberry Pi documents the current behaviour and the supported raspi-config control in its configuration guide.

Identify the symptom

What you see Meaning First action
[sudo] password for alice: Normal prompt for the current user's password Enter the password created during setup
Sorry, try again. The password is wrong, not a hidden SSH key passphrase Check the active username with whoami; reset the account password if needed
alice is not in the sudoers file The account lacks administrator permission Use a working administrator or local recovery path to add it to the sudo group
Script waits forever or reports a password is required An unattended command invoked interactive sudo Run the job as the intended service user or create a narrow sudoers rule
sudo: no tty present or no askpass program specified A non-interactive environment cannot answer the prompt Do not expect a cron, systemd, or CI job to supply a terminal password

Do not paste passwords into command lines, environment variables, Compose files, shell history, or source control.

1. Check the user and sudo access

Run these as the affected account:

1
2
3
4
whoami
id
groups
sudo -l

On a normal interactive shell, refresh the authentication timestamp and test a harmless privileged command:

1
2
sudo -v
sudo true

The prompt is for the account reported by whoami. Nothing is shown while you type a Linux password; that is expected. A successful sudo -v normally caches authentication briefly, but scripts must not rely on that cache.

2. Set or change the administrator account password

For the current user on a console or SSH session:

1
passwd

Enter the existing password when asked, then enter the new password twice. If the account was created in Raspberry Pi Imager with a password, use that same password for sudo.

If you have a desktop, open Control Centre → System → Change Password. On Lite and headless systems, passwd is the direct method.

You cannot authenticate at all

Use an already-working administrator account or a local console. From that account, reset the intended user's password and verify group membership:

1
2
3
sudo passwd alice
id alice
getent group sudo

Replace alice with the actual username. If it should be an administrator and is absent from the sudo group, add it, then log out and back in:

1
sudo usermod -aG sudo alice

Keep the current administrator session open until a second terminal proves that the repaired account can sign in and run sudo -v.

3. Turn off the prompt only when it fits the device

For a personal, physically controlled device, Raspberry Pi OS provides a supported switch:

1
sudo raspi-config

Choose 1 System Options → S10 Admin Password, then answer No to disable the password requirement for sudo. Reboot when raspi-config requests it. On the desktop, the equivalent is Control Centre → System → turn off Admin Password.

This changes the security boundary for every command the account can run with sudo. Keep the prompt enabled on shared, remotely reachable, or service-hosting devices unless you have a specific operational reason to remove it.

4. Repair scripts, cron jobs, and systemd services

An unattended job must never wait for a person to type a password. First locate every use of sudo in the project and scheduled jobs:

1
2
3
4
grep -RIn --exclude-dir=.git --exclude-dir=.venv 'sudo[[:space:]]' ~/services /opt 2>/dev/null
crontab -l
sudo crontab -l
systemctl list-unit-files --state=enabled

systemd service

Do not put sudo in ExecStart=. A system service already runs as root unless it has a User= directive. Prefer the least-privileged service account and give it only the filesystem, device, capability, or group access it needs.

1
2
3
4
[Service]
User=appuser
Group=appuser
ExecStart=/usr/local/bin/my-app

If the service genuinely needs a privileged operation, split that operation into a reviewed root-owned service or use an explicit, narrowly scoped privilege mechanism. Do not grant the whole application unrestricted root access merely to avoid a password prompt.

cron or CI

Use sudo -n during diagnosis. It fails immediately instead of hanging when authentication would be required:

1
sudo -n systemctl restart my-app.service

When the job is meant to run as root, install it in root's crontab from an administrator session. When it only needs to read a device or write a project directory, use correct Linux groups and ownership instead of sudo.

5. Use a narrow sudoers rule when it is truly necessary

Only an administrator can create a rule. Always edit and validate with visudo:

1
sudo visudo -f /etc/sudoers.d/backup-status

Example for an account that may run one fixed status command without a password:

1
backupbot ALL=(root) NOPASSWD: /usr/bin/systemctl status backup.service

Validate the complete configuration before closing the recovery session:

1
2
sudo visudo -c
sudo -l -U backupbot

The command path and its arguments matter. A broad rule such as NOPASSWD: ALL, a writable script behind a privileged wrapper, or permission to run a shell through an allowed command can turn a narrow exception into unrestricted root access.

Docker and Compose setups

The Docker daemon is privileged. Do not solve a password prompt by putting sudo inside docker-compose.yml, container entrypoints, or a startup script.

For interactive administration, add a trusted user to the Docker group and start a fresh login session:

1
sudo usermod -aG docker "$USER"

Membership in the Docker group is effectively root-equivalent on most Docker hosts. Restrict it to trusted administrators. For services, use a systemd unit with an intentional User= and a reviewed deployment process; see Docker Compose and Nginx Proxy Manager.

Recovery checklist for a remote Pi

  1. Keep the existing SSH connection open.
  2. Verify the current user with whoami and test sudo -v.
  3. Open a second SSH connection before changing account, group, or sudoers settings.
  4. Edit sudoers only through visudo -f /etc/sudoers.d/name.
  5. Run sudo visudo -c and sudo -l -U username.
  6. Confirm the intended command works from the second session.
  7. Retain a local-console, USB Gadget, or other recovery path before ending the first session.

FAQ

Why does sudo ask for a password after I updated the OS?

The prompt is the default for new current images. Raspberry Pi states that existing installations retain their previous passwordless setting unless it is changed, so also check whether the account, sudoers configuration, or automation environment changed during your migration.

Is the sudo password my SSH-key passphrase?

No. It is the password of the Linux account currently running the command. An SSH-key passphrase protects the private key on the client computer.

Can I use echo password | sudo -S in a script?

Do not. It exposes a reusable administrator secret to process listings, logs, shell history, files, or CI configuration. Redesign the job or use a strictly scoped sudoers rule.

Why does sudo work in SSH but fail in systemd?

Your SSH shell can show a password prompt and hold an authentication timestamp. A systemd service normally has neither an interactive terminal nor a human to answer it. Configure the service's account and privileges directly.

How do I return to the secure default?

Use sudo raspi-config → 1 System Options → S10 Admin Password, then choose Yes to require an administrator password. Remove any temporary /etc/sudoers.d/ exception only after confirming it is no longer required.