🚨 Sudo Error: 'sudo: no tty present and no askpass program specified' — Cause, Fix, and Troubleshooting Guide

What this error means

sudo needs to prompt for a password, but the process running it has no interactive terminal and no configured askpass helper, so it gives up rather than block forever. This is the classic failure when a script that works interactively is moved into cron, a CI job, a systemd unit, or a non-interactive ssh host 'sudo ...' invocation.

sudo: no tty present and no askpass program specified

The message is two facts joined: there is no tty to read a password from, and there is no askpass program (SUDO_ASKPASS / -A) to obtain one another way. sudo therefore cannot authenticate and exits non-zero without running the command.

How it manifests on the host

• A command that works when you run it by hand fails only from cron, CI, a deploy tool, or ssh host 'sudo ...'.
• The job exits non-zero immediately with the message above and never runs the intended command.
• sudo -n true returns sudo: a password is required, confirming a password would be prompted.
• Interactive ssh host then sudo works, but a single non-interactive ssh host 'sudo ...' does not.

System configuration causes

• Non-interactive context. cron, CI runners, systemd ExecStart=, and ssh host 'command' allocate no tty, so sudo has nothing to prompt on.
• Password-required sudoers rule. The user’s sudo rule does not include NOPASSWD, so every invocation wants a password.
• requiretty still set. An older /etc/sudoers (or a leftover Defaults line) sets requiretty, which rejects sudo without a controlling terminal even when a password is not needed.
• No askpass configured. SUDO_ASKPASS is unset and -A is not used, so sudo has no GUI/helper fallback.
• Cached credentials expired. A script relied on a prior interactive sudo timestamp that has since timed out.

Interrogating the host

# Would this command prompt for a password? (-n = never prompt)
sudo -n true; echo "exit=$?"

# What sudo privileges does this exact user have?
sudo -l -U "$USER"

# Is requiretty set anywhere?
sudo grep -R --include='*' requiretty /etc/sudoers /etc/sudoers.d 2>/dev/null

# Reproduce the non-interactive case
ssh localhost 'sudo id' 2>&1 | tail -2

sudo -l shows whether the relevant rule carries NOPASSWD. A requiretty hit explains failures even when the password is not the problem.

Remediation

1. Grant a scoped NOPASSWD rule (preferred for automation). Restrict to the exact commands the job runs, never blanket ALL:

sudo visudo -f /etc/sudoers.d/deploy
# content (validated on save):
#   deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp, /usr/bin/nginx -t
sudo visudo -cf /etc/sudoers.d/deploy   # syntax check

2. Remove a lingering requiretty. If present, drop it (modern sudo does not need it):

sudo visudo    # delete: Defaults requiretty   (or scope it: Defaults:deploy !requiretty)

3. Feed the password over stdin only from a secret store, never a literal:

printf '%s\n' "$SUDO_PW" | sudo -S -p '' systemctl restart myapp

4. Use an askpass helper when a NOPASSWD rule is not acceptable:

export SUDO_ASKPASS=/usr/bin/ssh-askpass   # or a script that prints the secret
sudo -A systemctl restart myapp

5. Force a tty for the SSH case when interactive auth is genuinely required:

ssh -t host 'sudo systemctl restart myapp'

Hardening the host

• Never hardcode passwords in scripts, cron files, or CI logs; source them from a secret manager and pass via stdin.
• NOPASSWD: ALL defeats the purpose of sudo — scope every rule to specific binaries and, where possible, specific arguments.
• Always validate sudoers edits with visudo -c; a broken sudoers file can lock out all sudo access.
• -t allocates a tty and disables SSH multiplexing benefits; reserve it for cases that truly need a prompt.
• An askpass script that echoes a secret is only as safe as its file permissions (chmod 700, root-owned).

Related system errors

• Building Least-Privilege sudoers Rules with AI
• SELinux ‘avc: denied’ Error Guide
• CIS Benchmark Hardening for Linux Servers