It's my understanding that the requiretty option does not allow sudo on PTYs.

My VM's sudoers:

# This file MUST be edited with the 'visudo' command as root.
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
# See the man page for details on how to write a sudoers file.
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
Defaults        passwd_tries=3
Defaults        badpass_message="WRONG PASSWORD T_T"
Defaults        log_input, log_output, iolog_dir="/var/log/sudo"
Defaults        requiretty
# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d`

After connecting to this system with SSH, the tty program outputs /dev/pts/0.

But I can still sudo with a password in the SSH session. Does this requiretty option have nothing to do with SSH or PTYs? How can I sudo in my SSH session?

1 Answer 1


Your understanding is not correct: a pseudo-TTY is considered fully equivalent to a "real" TTY.

When tty prints /dev/pts/0 it means the session has a valid TTY.

But if you connect to the VM with SSH default settings and specify the command to run, the situation will be different:

$ ssh VM-user@VM-hostname "hostname; tty"
not a tty

and that is the situation rejected by sudo's requiretty option.

The requirement for a TTY allows SSH to reject attempts to pipe in the response to the password prompt via standard input, like many other Unix programs do when requesting a password.

It also allows you to do things like this:

sudo -u some-user data_producing_command 2> error-log-file | data_consuming_command

without the password prompt getting neither mixed in to the data piped to data_consuming_command, nor into the error-log-file. (Note that data_consuming_command here is run as yourself, not as some-user!)

In other words, with requiretty set, you cannot use sudo in contexts like:

  • remote commands via SSH unless you force TTY allocation, i.e. ssh VM-user@VM-host sudo something would fail, but ssh -tt VM-user@VM-host sudo something would succeed.
  • crontab commands, or scripts executed via crontab or at or batch commands
  • scripts executed via nohup
  • scripts executed via cgi-bin or any other daemonized process that has no relationship to user sessions

When requiretty is set and sudo is requesting a password, it does that in a way that is roughly similar in concept to this script snippet:

printf "[sudo] password for $USER: " > /dev/tty  # display prompt

TTYSETTINGS=$(stty -F /dev/tty --save)  # save current TTY settings
stty -F /dev/tty -echo -echoe           # prevent displaying the password

read PASSWORD < /dev/tty  

stty -F /dev/tty $TTYSETTINGS           # restore TTY settings 
# now check if $PASSWORD is correct...

/dev/tty is a "magic" device that will always act as an alias of the session's actual TTY device, if the session has a TTY. It exists precisely for things like this: to allow any script or program to "escape" piping or other input/output redirection and interact directly with the user when necessary.

If requiretty is set and /dev/tty is not usable (i.e. when the process has no real TTY associated with it), it is treated the same as a password authentication failure.

  • Thanks! It is a big help to me. My understanding was wrong.
    – mishy
    Commented Jun 2, 2021 at 5:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .