🚨 Linux Error Guide: 'sudo: no tty present and no askpass program specified' — run sudo non-interactively

Overview

A command that needs sudo fails from a script, cron job, CI runner, or non-interactive SSH command with:

sudo: no tty present and no askpass program specified

The message means sudo needed to prompt for a password but had nowhere to read it from: there is no controlling terminal (TTY) to type into, and no configured askpass helper to supply it programmatically. This is a context problem, not a permissions problem — the same command usually works fine when you run it by hand in an interactive shell.

Symptoms

• A sudo command works interactively but fails inside a cron job, systemd unit, CI pipeline, or ssh host 'sudo ...'.
• The error appears immediately, with no password prompt shown.
• Removing sudo (or running as root directly) makes the command succeed.
• Ansible, Jenkins, GitLab CI, or a deploy script reports the failure while a human running the same play/step does not see it.
• A one-off ssh -t host 'sudo ...' works, while the same command without -t fails.

Common Root Causes

• No password rule for the command — the account is not granted NOPASSWD for what it is running, so sudo tries to prompt.
• Defaults requiretty in sudoers forces a real terminal and rejects TTY-less callers outright.
• Non-interactive SSH (ssh host 'sudo ...' without -t) does not allocate a PTY.
• Cron / systemd / CI context — these run detached with no controlling terminal by design.
• No SUDO_ASKPASS helper configured, so sudo -A has nothing to call for the password.
• Automation running as the wrong user (e.g. a service account) that was never granted the needed sudo rights.

Diagnostic Workflow

Confirm what the current context can and cannot do:

tty                                  # "not a tty" confirms no terminal
id                                   # which user is actually running this
sudo -n true; echo "exit=$?"         # -n = non-interactive; nonzero means a password would be required

List exactly what sudo rights the running user has (this itself may need a password):

sudo -ln                             # shows NOPASSWD entries usable without a TTY

Check whether requiretty is forcing the failure:

sudo grep -R requiretty /etc/sudoers /etc/sudoers.d/ 2>/dev/null

Reproduce the non-interactive path the automation actually uses:

ssh user@host 'sudo systemctl restart nginx'      # fails: no PTY
ssh -t user@host 'sudo systemctl restart nginx'   # forces a PTY

Always edit sudoers safely so a typo cannot lock you out:

sudo visudo -f /etc/sudoers.d/automation
sudo visudo -c                        # validate syntax before trusting it

Example Root Cause Analysis

A nightly cron job on a web server that restarted a service started failing silently. The cron log showed:

/opt/deploy/rotate.sh: line 12: sudo: no tty present and no askpass program specified

The script ran as the deploy user and called sudo systemctl reload nginx. Interactively it worked because the admin typed the password; under cron there was no TTY and no NOPASSWD rule, so sudo had nothing to do but fail. Checking the grant:

sudo -ln -U deploy

User deploy may run the following commands on web01:
    (ALL) ALL

The account could run the command, but only with a password. The correct, least-privilege fix was to grant password-less sudo for that one exact command instead of allocating a fake terminal in cron. In /etc/sudoers.d/deploy via visudo:

deploy ALL=(root) NOPASSWD: /bin/systemctl reload nginx, /bin/systemctl restart nginx

After sudo visudo -c validated the file, the cron job ran cleanly. The scope was deliberately narrowed to the specific systemctl actions rather than NOPASSWD: ALL, so a compromised script could not escalate to arbitrary root commands.

Prevention Best Practices

• Grant NOPASSWD only for the specific commands automation needs, never NOPASSWD: ALL, and use full binary paths.
• Always edit sudoers with visudo (or visudo -f for drop-ins) and validate with visudo -c before relying on it.
• Avoid Defaults requiretty on hosts that run automation; if it is mandated, scope it with a Defaults:user !requiretty exception.
• For interactive remote admin that needs prompts, use ssh -t; for unattended jobs, use NOPASSWD or an askpass helper instead.
• In Ansible use become: true with a vaulted become_password rather than fabricating TTYs; in CI, run privileged steps as a dedicated, tightly-scoped account.
• Keep an SUDO_ASKPASS helper (e.g. a wrapper reading from a secret store) for the rare cases that genuinely need a password non-interactively, and call sudo -A.

Quick Command Reference

# Is there a TTY, and who am I?
tty
id

# Would this sudo need a password? (0 = no)
sudo -n true; echo $?

# What can this user run without a password?
sudo -ln
sudo -ln -U <user>

# Is requiretty forcing failure?
sudo grep -R requiretty /etc/sudoers /etc/sudoers.d/

# Safely grant NOPASSWD for one command
sudo visudo -f /etc/sudoers.d/automation
sudo visudo -c

# Force a PTY for interactive remote sudo
ssh -t user@host 'sudo <command>'

Conclusion

sudo: no tty present and no askpass program specified is not a permission denial — it means sudo wanted a password and had no terminal to ask on and no askpass helper to ask with. The fix depends on intent: for unattended cron, systemd, and CI work, grant tightly-scoped NOPASSWD rules for the exact commands involved; for interactive remote administration, allocate a PTY with ssh -t. Reserve askpass helpers for genuine edge cases. Editing sudoers only through visudo and scoping grants to specific binaries keeps this fix from becoming a privilege-escalation hole.