Ensure sudo commands use pty is a CIS Linux benchmark check that fails when sudo is not set to run commands inside a separate pseudo-terminal. To fix it, add Defaults use_pty to /etc/sudoers or a drop-in file under /etc/sudoers.d/ using visudo, validate with visudo -c, then rescan the host.

What the scanner is actually detecting

This finding comes from Tenable’s CIS Linux audit files, which Nessus runs as a credentialed Unix compliance check. It is a configuration check, not a vulnerability plugin, so there is no CVE and no package to update. The title carries a benchmark-specific number: it appears as 5.3.2 Ensure sudo commands use pty in the CIS CentOS Linux 8 Server L1 audit and as 5.2.2 in the CIS Amazon Linux 2 v2.0.0 audit, for example. Tenable files it under the Access Control category.

The remediation text asks for one explicit line, Defaults use_pty, in /etc/sudoers or in a file under /etc/sudoers.d/. The same benchmarks usually include a companion item, Ensure sudo log file exists (5.3.3 in the CentOS 8 audit), which asks for a line such as Defaults logfile="/var/log/sudo.log". Because the audit reads the sudoers files themselves, it needs a scan account with enough privilege to read them. If your compliance scans return a lot of unreadable or skipped items, review how you are setting up a credentialed Linux scan over SSH with sudo before chasing individual findings.

Real-world risk

Without use_pty, the command that sudo starts shares your terminal. The sudoers manual describes two abuses that this allows: a malicious program run under sudo injecting commands into your terminal, and a background process keeping access to your terminal device after the main program has finished. The classic injection technique uses the TIOCSTI ioctl to push characters into the terminal’s input queue, which your shell then executes as you once sudo returns. With use_pty, the command runs in its own pseudo-terminal and that path is closed.

Keep the severity in proportion. This is a hardening control, not a remotely exploitable flaw. An attacker first needs a program that someone runs through sudo: a tampered script, a compromised third-party installer, or a command run with sudo -u as a less trusted service account. Recent Linux kernels can also restrict TIOCSTI through the dev.tty.legacy_tiocsti sysctl, but the kernel documentation notes that processes with CAP_SYS_ADMIN can still use it, and the sysctl does nothing about lingering background processes. use_pty covers both cases, whatever the kernel.

How to confirm it on the host

Start by checking the sudo version and what the sudoers files actually contain:

sudo -V | head -n 1
sudo grep -rEn '^s*Defaults.*use_pty' /etc/sudoers /etc/sudoers.d/
sudo grep -En '^s*[@#]includedir' /etc/sudoers

The second command lists both use_pty and !use_pty lines, so you can spot a line that turns the setting back off. The third confirms that /etc/sudoers actually reads the drop-in directory. Next, check the effective setting. When run by root, sudo -V also prints the sudoers plugin’s active defaults:

sudo -i
sudo -V | grep -Ei 'pseudo-tty|log file'
exit

If use_pty is active, the output includes Always run commands in a pseudo-tty. If a log file is configured, you will also see Path to log file: /var/log/sudo.log. For a quick behavioral test, compare tty with sudo tty. With use_pty on, the second command reports a different /dev/pts/N device, because the command is running in a new pseudo-terminal.

How to fix it

The sudoers syntax is the same on every distribution that ships sudo (RHEL and its rebuilds, Amazon Linux, Debian, Ubuntu, SUSE). Always edit through visudo, which locks the file and refuses to save a syntax error, and keep a second root session open until you have tested sudo from a fresh login.

Option 1: a drop-in file (recommended)

A dedicated file is easy to deploy, audit and remove. First confirm that /etc/sudoers contains @includedir /etc/sudoers.d (older releases write it as #includedir, which is still a directive and not a comment), then create the file:

sudo visudo -f /etc/sudoers.d/01-hardening

Add these lines and save:

Defaults use_pty
Defaults logfile="/var/log/sudo.log"

The second line is optional for this item but satisfies the companion log file check. Two rules from the sudoers manual matter here. First, sudo skips any file in /etc/sudoers.d whose name contains a dot or ends in ~, so 01-hardening.conf would be silently ignored. Second, Defaults entries are applied in order and later entries override earlier ones, and drop-in files are read in lexical order. A Defaults !use_pty line in /etc/sudoers after the include, or in a later file, will switch the setting back off. Remove any such line.

Option 2: edit /etc/sudoers directly

sudo visudo

Add Defaults use_pty next to the existing Defaults lines, and delete any Defaults !use_pty line.

Option 3: non-interactive rollout

For configuration management or a fleet script, validate the file before installing it with the ownership and mode that sudo expects (root-owned, 0440):

printf '%sn' 'Defaults use_pty' 'Defaults logfile="/var/log/sudo.log"' > /tmp/01-hardening
sudo visudo -cf /tmp/01-hardening && 
  sudo install -o root -g root -m 0440 /tmp/01-hardening /etc/sudoers.d/01-hardening
sudo visudo -c

The final visudo -c checks /etc/sudoers and every file it includes, and exits with a non-zero status if anything fails to parse.

How to verify the fix and rescan

sudo visudo -c
sudo -i
sudo -V | grep -Ei 'pseudo-tty|log file'
exit
tty; sudo tty
sudo true && sudo tail -n 2 /var/log/sudo.log

Expect Always run commands in a pseudo-tty from sudo -V, two different pts devices from the tty comparison, and a fresh entry in the log. sudo creates the log file on the first logged command, owned by root with mode 0600, so it is normal for it not to exist until then. Nothing needs restarting, because sudo reads its configuration on every run. Then rerun the same compliance scan, with the same audit file and credentials, against the host.

What can break and how to roll back

A syntax error disables sudo. The Tenable audit’s own impact note warns about this. Using visudo and a second root session removes most of the risk.
Keystrokes during non-interactive commands. The sudoers manual documents a side effect: input is passed to the command even if it is non-interactive, so keys you type while it runs are consumed by sudo instead of reaching your shell afterward.
Jobs that relied on your terminal. A process started through sudo can no longer keep reading from or writing to your terminal after the sudo command returns. That is the intended effect, but it can surprise people who launch long jobs that way.
Older sudo and -b. The sudo 1.9.14 release notes list the -b (background) option as now working when the command runs in a pseudo-terminal. On older releases, test any scripts that use sudo -b.
The log file grows. Add /var/log/sudo.log to your log rotation. The ignore_logfile_errors flag is on by default, so a log write failure does not block commands.

Cron jobs and scripts that run sudo without a terminal are not affected, because use_pty has no effect when sudo is not attached to a terminal. To roll back, remove the drop-in and revalidate:

sudo rm /etc/sudoers.d/01-hardening
sudo visudo -c

On sudo 1.9.14 and later, use_pty is on by default, so removing the file does not restore the old behavior; the release notes say to add Defaults !use_pty for that. If a single tool genuinely needs it, scope the exception with a user-specific (Defaults:user) or command-specific (Defaults!command) entry instead of disabling it globally, and record it as an accepted deviation, since the audit may still flag it.

Common false positive reasons

sudo 1.9.14 or later with no explicit line. The sudoers manual states that use_pty is on by default from 1.9.14. Since the remediation asks for an explicit Defaults use_pty line, a host can fail the check while sudo -V as root already shows the setting active. Adding the explicit line is harmless and closes the finding.
The scan account cannot read the drop-ins. Files in /etc/sudoers.d are normally mode 0440 and owned by root, so an unprivileged scan account cannot see a line that is really there.
Stale results. The report predates the change, or the rescan used a different audit file or no credentials.

Some findings look false but are real: the line sits in a file sudo ignores (a name with a dot), a later !use_pty overrides it, /etc/sudoers has no include line for the directory, or the line is commented out.

FAQ

Does use_pty affect cron jobs and scripts?

Not when they run without a terminal. The sudoers manual states that use_pty has no effect if the sudo process is not attached to a terminal.

Is use_pty the same as requiretty?

No. requiretty refuses to run sudo at all unless the user is logged in to a real tty, which blocks cron and similar uses. use_pty only changes how the command runs once sudo is called from a terminal.

Do I need to restart anything?

No. sudo is not a daemon; it reads the sudoers files every time it runs, so the change applies to the next sudo command.

Does setting logfile stop sudo logging to syslog?

No. By default sudo logs through syslog, and setting logfile turns on file logging as well. Both are kept unless you disable syslog explicitly.

Tracking this finding across many hosts

When the same configuration finding shows up on dozens of Linux hosts, the one-line fix is the easy part; proving every host is closed is harder. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners (Nessus results arrive as an uploaded .nessus export) and merges duplicates reported by the same scanner. Its AI can draft host-specific remediation scripts that run only after human approval, deployed by SITEY agents on Linux endpoints, and SITEY re-tests afterward to verify closure.

Discovery and visibility

Scanning and collection

The AI layer

Action and closure

Team and governance

Reporting

Ensure sudo commands use pty: how to fix the CIS finding