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@host.example.net -- sudo id
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
sudo: a password is required

sudo could also report a similar error depending on version.

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.

Steps to fix sudo: no tty present and no askpass program specified error in SSH:

  1. Allocate a pseudo-terminal for the SSH session to provide the necessary tty.
    $ ssh -t user@host.example.net -- "echo UserPassw0rd! | sudo -S id"
    uid=0(root) gid=0(root) groups=0(root)
    -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 "UserPassw0rd!" | ssh user@host.example.net -- sudo -S id
    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.
  4. Install an askpass helper program from the distribution repositories on the SSH server.
    $ sudo apt update && sudo apt install --assume-yes ssh-askpass
    Hit:1 http://ports.ubuntu.com/ubuntu-ports noble InRelease
    Get:2 http://ports.ubuntu.com/ubuntu-ports noble-updates InRelease [126 kB]
    Hit:3 http://ports.ubuntu.com/ubuntu-ports noble-backports InRelease
    Hit:4 http://ports.ubuntu.com/ubuntu-ports noble-security InRelease
    Fetched 126 kB in 3s (40.9 kB/s)
    Reading package lists...
    Building dependency tree...
    Reading state information...
    All packages are up to date.
    Reading package lists...
    Building dependency tree...
    Reading state information...
    The following NEW packages will be installed:
      ssh-askpass
    0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
    Need to get 24.4 kB of archives.
    After this operation, 124 kB of additional disk space will be used.
    Get:1 http://ports.ubuntu.com/ubuntu-ports noble/universe arm64 ssh-askpass arm64 1:1.2.4.1-16build2 [24.4 kB]
    Fetched 24.4 kB in 1s (33.9 kB/s)
    Selecting previously unselected package ssh-askpass.
    (Reading database ... 
    (Reading database ... 5%
    (Reading database ... 10%
    (Reading database ... 15%
    (Reading database ... 20%
    (Reading database ... 25%
    (Reading database ... 30%
    (Reading database ... 35%
    (Reading database ... 40%
    (Reading database ... 45%
    (Reading database ... 50%
    (Reading database ... 55%
    (Reading database ... 60%
    (Reading database ... 65%
    (Reading database ... 70%
    (Reading database ... 75%
    (Reading database ... 80%
    (Reading database ... 85%
    (Reading database ... 90%
    (Reading database ... 95%
    (Reading database ... 100%
    (Reading database ... 37324 files and directories currently installed.)
    Preparing to unpack .../ssh-askpass_1%3a1.2.4.1-16build2_arm64.deb ...
    Unpacking ssh-askpass (1:1.2.4.1-16build2) ...
    Setting up ssh-askpass (1:1.2.4.1-16build2) ...
    update-alternatives: using /usr/libexec/ssh-askpass/x11-ssh-askpass to provide /usr/bin/ssh-askpass (ssh-askpass) in auto mode

    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. Create a simple askpass helper script for non-interactive use.
    #!/bin/sh
    echo "UserPassw0rd!"

    Store passwords in secure secrets tooling or an approved password manager on production systems instead of embedding them in scripts.

  6. Use SUDO_ASKPASS with the -A option so sudo invokes the helper instead of prompting on a tty in non-interactive sessions.
    $ ssh user@host.example.net -- "SUDO_ASKPASS=/usr/local/bin/sudo-askpass.sh SSH_ASKPASS_REQUIRE=force sudo -A id"
    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.