agent's sudo session timed out mid upgrade and privilege escalation failed

TL;DR

sudo credentials are cached per session for a short window (commonly 5 to 15 minutes), and a long quiet install outlives the cache; the next sudo call then demands a password the agent cannot supply interactively. Design around it: run the privileged work inside one elevated session or service (a single sudo-wrapped runner script copied to the host), refresh the timestamp deliberately with sudo -v at step boundaries where a TTY design is kept, or use a narrowly scoped NOPASSWD sudoers rule for the specific patch commands owned by the service account.

agent's sudo session timed out mid upgrade and privilege escalation failed

Use this when

• Early steps on a host succeed and later ones fail with sudo: a password is required or sudo: a terminal is required to read the password.
• The failures correlate with long installs between privileged steps.
• Interactive testing works because a human re-enters the password when asked.

Not for this skill when

• The service account has no sudo rights for the failing command at all. That is a sudoers design task, not a timeout.
• The account is locked or its password expired at the directory level. Different failure, directory fix.

Steps

1. Identify where escalation breaks: the step, the elapsed time since the last successful sudo, and the host sudo timeout setting (timestamp_timeout in sudoers). Verify: the timing correlation is shown from logs
2. Restructure to a single elevated runner: the agent copies one reviewed runner script to the host and executes it with one sudo invocation; all privileged steps happen inside it, reporting results to a log. Verify: a long host operation uses exactly one escalation
3. If the framework cannot restructure, add timestamp refresh at step boundaries (sudo -v) inside the session and keep a TTY allocated for the host session. Verify: refresh events appear in the log and long gaps no longer break escalation
4. Where policy allows, scope a NOPASSWD rule to the exact patch commands and the service account, reviewed by the security owner. Verify: the rule is command-specific, not a blanket all-commands grant
5. Test on the slowest host class end to end. Verify: privileged steps complete across a duration several times the sudo timeout

Variant phrasings

sudo session timed out mid upgrade agent timestamp_timeout

The main phrasing.

sudo a terminal is required agent non interactive runner

The error-string phrasing.

single elevated runner script patch host sudo design

The design phrasing.

Compatibility: Compatibility: sudo on Linux and BSD; sudoers policy may be centrally managed (LDAP or config management) on fleets.

Why it happens

sudo timestamp cache is a convenience for humans at keyboards: it assumes the same person is present minutes later to re-authenticate. An agent holding a session across a 40-minute install violates that assumption structurally. The robust patterns all remove repeated escalation from the design, either by doing the privileged work inside one invocation or by replacing the password check with a tightly scoped policy grant for a service account, which is also more auditable.

Edge cases / pitfalls

• A blanket NOPASSWD ALL rule for the agent account converts every agent bug into a root compromise; scope to commands and argue each one.
• sudo -v refresh loops keep a session alive but also keep a stolen session useful; prefer the single-runner design where possible.
• Log every privileged command from the runner; after restructuring, that log is the audit trail sudo would have provided per command.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstM8FuPVvXRxr0VIe9jNBag