How to fix the "sudo: no tty present and no askpass program specified" error

Encountering the error sudo: no tty present and no askpass program specified during remote commands or automation prevents elevation and breaks workflows that depend on sudo. Non-interactive jobs such as deployment scripts, orchestration tools, and scheduled tasks often call sudo over SSH, so a failed password prompt stops the entire sequence.

The sudo program normally expects a controlling terminal (tty) to read passwords and can optionally use an askpass helper to obtain credentials in graphical or scripted environments. When an SSH connection does not allocate a pseudo-terminal, sudo cannot display its prompt, and different versions may show related messages such as a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper. Automated SSH sessions therefore need either a tty or an alternate password delivery method to succeed.

$ ssh user@simplified.guide -- sudo ls
user@simplified.guide's password:
sudo: no tty present and no askpass program specified

sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper

Several approaches avoid these errors: forcing pseudo-terminal allocation in the SSH client, making sudo read from standard input with the --stdin or -S option, configuring passwordless rules for specific commands, or using a dedicated askpass helper. Each method trades convenience against security, so elevated access in automated setups should prefer narrowly scoped sudoers entries and avoid exposing plaintext passwords in scripts or logs wherever possible.

1. Allocate a pseudo-terminal for the SSH session to provide the necessary tty.

   $ ssh -t user@example.com -- sudo id
   user@example.com's password:
   [sudo] password for user:
   uid=0(root) gid=0(root) groups=0(root)
   Connection to example.com closed.

   -t      Force pseudo-terminal allocation.  This
           can be used to execute arbitrary screen-
           based programs on a remote machine, which
           can be very useful, e.g. when implement-
           ing menu services.  Multiple -t options
           force tty allocation, even if ssh has no
           local tty.

2. Force sudo to read the password from standard input by using the --stdin or -S switch in scripted usage.

   $ echo "password" | ssh user@example.com -- sudo -S id
   user@example.com's password:
   [sudo] password for user:
   uid=0(root) gid=0(root) groups=0(root)

   The literal password appears in the command line and shell history in this example and should be replaced with a safer secret-handling mechanism on real systems.

   -S, --stdin Write the prompt to the standard
               error and read the password from
               the standard input instead of using
               the terminal device.

3. Configure passwordless sudo for the relevant user and command on the SSH server.

   $ ssh user@example.com -- sudo id
   user@example.com's password:
   uid=0(root) gid=0(root) groups=0(root)

   Related: How to configure passwordless sudo on Linux

4. Install an askpass helper program from the distribution repositories on the SSH server.

   $ sudo apt install --yes ssh-askpass

   The askpass program provides passwords to sudo in environments without a usable tty, typically in combination with the SUDO_ASKPASS variable and the -A option.

5. Use SUDO_ASKPASS with the -A option so sudo invokes the helper instead of prompting on a tty in non-interactive sessions.

   $ export SUDO_ASKPASS=/usr/bin/ssh-askpass
   $ ssh user@example.com -- SUDO_ASKPASS=/usr/bin/ssh-askpass sudo -A id
   user@example.com's password:
   [sudo] password for user:
   uid=0(root) gid=0(root) groups=0(root)

   The -A option instructs sudo to call the askpass helper referenced by SUDO_ASKPASS instead of attempting to read a password directly from the terminal.