PAM and sudo issues

Troubleshooting guide for sudo with MFA and the Alpamon PAM module (alpamon-pam). Each section starts with the message you see, then explains the cause and the fix.

”A terminal is required to authenticate”

On sudo-rs hosts (Ubuntu 25.10 and later), a sudo command run without a terminal—for example through alpacon exec—can fail with:

sudo: A terminal is required to authenticate

This means the sudo attempt did not complete Alpacon authorization. Unlike classic sudo, sudo-rs cannot show the reason when no terminal is attached, so it prints this generic message instead. The most common causes are:

  • The command was denied—for example, no sudo policy on the work session matches it—and the reason is hidden because there is no terminal.
  • sudo with MFA is disabled for the workspace.
  • Alpamon is not running on the server.
  • The sudo command did not originate from a tracked Alpacon session.

Find the real cause: run journalctl -u alpamon on the server around the time of the attempt and look for these lines.

Log lineMeaning
No session found for PIDThe sudo did not come from a tracked Alpacon session. Run it inside an approved work session or an interactive Websh session.
sudo_approval response timeoutAlpacon sent the request but received no answer from the server in time. Check connectivity and retry.
Processing sudo_approval response with approved=false and an error_codeThe command was explicitly denied. Look up the code in “Alpacon denied this sudo command”.

The user has no sudoers rule

Depending on the sudo implementation, a user with no permission to run sudo sees one of:

# sudo-rs (Ubuntu 25.10+)
sudo: I'm sorry user. I'm afraid I can't do that

# classic sudo
user is not in the sudoers file.

On Alpacon-managed hosts, the sudoers rule that grants sudo through Alpacon (%alpacon) is installed together with the PAM module (alpamon-pam). Seeing this message usually means alpamon-pam is not installed on the server. Check whether the package is present:

bash
# Debian/Ubuntu
dpkg-query -W alpamon-pam
 
# RHEL/CentOS/Rocky/Alma/Fedora
rpm -q alpamon-pam

To reinstall it:

  • A single server: install the package with the system package manager—apt-get install -y alpamon-pam on Debian/Ubuntu, yum install -y alpamon-pam on RHEL-based systems. See installation.
  • The whole workspace: if Sudo through Alpacon is turned off, turning it back on in Access rules reinstalls alpamon-pam on all currently connected servers.

”Alpacon denied this sudo command”

When Alpacon blocks a sudo command, it returns a message with an error code:

Alpacon denied this sudo command (SUDO_NO_WORKSESSION_POLICY)

The code tells you why it was denied and what to do.

CodeMeaningWhat to do
SUDO_SESSION_MISSINGThe command was not started under an approved session.Run sudo inside an approved work session or an interactive Websh session.
SUDO_NO_WORKSESSION_POLICYThe work session has no sudo policy that matches this command.Add a matching pattern with work-session update --sudo, and check the pattern rules—the sudo prefix is not part of the matched command, the whole command must match, and * is the only wildcard.
WORKSPACE_SUDO_WITH_MFA_DISABLEDSudo through Alpacon is turned off for the workspace.Ask a Superuser to turn it on in Access rules.
SUDO_APPROVAL_REQUIREDThe command needs a person’s approval, and an approval request was sent.Run the same command again once it is approved. See When sudo is refused.
SUDO_APPROVAL_PENDINGThe terminal waited for an approval and the wait ended or you stopped it with Ctrl+C, or the identity (MFA) check was not finished in time. The request stays open.Run the same command again once it is approved. See Waiting for approval.
SUDO_APPROVAL_ALREADY_WAITINGThe same sudo command is already waiting for approval in another terminal.Use the terminal that is waiting, or press Ctrl+C there first. See Waiting for approval.
SUDO_APPROVAL_REJECTEDAn approver turned the request down, or it was withdrawn.The command did not run. Ask the approver why, or request it again with a clearer reason.
APPROVAL_NO_OTHER_APPROVERNobody but you could approve this request, and you can’t approve your own.Ask a Superuser to add a second approver or an auto-approve rule.
SUDO_NO_AUTHORITYNo standing sudo authority covers this command. In an Advisory workspace, it is refused at once without an approval request.Ask a workspace owner for a standing sudo grant under Server access policies. See When nothing waits.
SUDO_TARGET_OTHER_PERSONThe command switches into another person’s personal account, which is always blocked.Run the command from your own account or a shared or service account.
SUDO_TARGET_UNPARSEDThe account the command switches into cannot be read, so the command is blocked.Rewrite the command so the target account is explicit.
SUDO_INTENT_DEVIATIONThe command doesn’t match the purpose of its work session, and an approval request was sent.Wait for the approval, or request a new work session for the changed work. See When sudo is refused.
SUDO_RISK_DENIEDThe workspace’s access rules block the command, or it was judged too risky.Ask a Superuser to review the access rules. See When sudo is refused.

Find the console messages for sudo_session_missing, sudo_no_worksession_policy, and workspace_sudo_with_mfa_disabled in the error message reference.

Verifying the installed PAM module

The server detail page shows Sudo through Alpacon for each server:

  • Active, with the alpamon-pam version, when the module is installed.
  • Inactive, when alpamon-pam is missing.
  • Unknown, when the agent is too old to report it. Update alpamon to see the state.
  • Not applicable, when the setting is off or the server is not Linux.

This is the last state the agent reported. It does not change when the package is removed or changed directly on the host. When in doubt, verify on the server itself:

bash
# Debian/Ubuntu
dpkg-query -W alpamon-pam
 
# RHEL/CentOS/Rocky/Alma/Fedora
rpm -q alpamon-pam
Last updated: