The requiretty Option of sudo

1. Introduction

The sudoers plugin of sudo has many options to control the permissions context for a given command, user, or session. One of these options is requiretty, which poses a limitation over the terminal and shell we use when using sudo.

In this tutorial, we explore the requiretty option and its effects. First, we discuss terminal allocation in general. After that, we focus on requiretty, how it works, and why it might or might not be useful.

We tested the code in this tutorial on Debian 11 (Bullseye) with GNU Bash 5.1.4. It should work in most POSIX-compliant environments unless otherwise specified.

2. Terminal Allocation

When using a pseudo-terminal (PTY, pty), we connect its input and output to the respective streams of another device, such as a teletypewriter (TTY, tty), physical terminal, or similar. This way, we can interact with a remote point from a local interface.

However, not all sessions are interactive. For example, we might just run an automated SSH command and exit. In such a scenario, we won’t require any interaction, so we might leverage SSH options like -T to disable pseudo-terminal allocation:

$ ssh -T xost 'touch /timestamp'

Here, we connect to xost and create the /timestamp file via touch without allocating a [-T]erminal.

On the other hand, some sessions need to be interactive:

$ ssh -t xost 'vi /file'

In this case, we use vi to manually edit /file, so we need to have a [-t]erminal available.

Of course, these SSH options are just an easy way to control allocation but are by far not the only way to get or dismiss terminals. Importantly, the default behavior depends on several factors, such as the other ends of current standard streams, the tool in use, and others.

3. requiretty

The sudoers config files can include an option that elevates privileges based on the current terminal:

Defaults        requiretty

In short, requiretty forces sudo to ensure we are in a logged-in TTY session. If we set the option, but the conditions are not met, we get an error:

$ ssh -T localhost 'sudo test'
[...]
sudo: sorry, you must have a tty to run sudo

In fact, we can set or unset (! exclamation point prefix) the option for a single user:

Defaults:baeldung        requiretty

One of the main reasons we use requiretty is protection from possibly rogue cron, apache, and other scripts:

$ cat /etc/crontab
[...]
0 6 * * * /backup.sh
$ cat /backup.sh
sudo rsync -av --delete /root/ /backup/root/

In this case, we can cause unwanted deletions from the /root directory by rsync. In another context, limiting the exposure based on the current web server user prevents many exploits from gaining superuser privileges.

If requiretty is disabled, we allow any sudo user to be remotely and automatically exploited to acquire full access to the system. Still, the limitations posed by requiretty are sometimes easy to circumvent and work around as it only works with sudo.

Because of the above and the fact that the feature often interferes with automated development and setup, requiretty is off by default.

4. Summary

In this article, we talked about terminal allocation and the role of requiretty when using sudo.

In conclusion, although requiretty can provide valuable protection, its use is fairly limited and limiting.