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.
  • 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, openSUSE/SLES
rpm -q alpamon-pam

To reinstall it:

  • A single server: from Alpacon, click Install or upgrade alpamon-pam on the server’s Agent card or run alpacon agent install-pam <server> with the CLI. Both send the install_pam action, which installs the package as root through the host’s package manager. While Sudo through Alpacon is off for the workspace, the button is disabled and the CLI request is refused, so turn the setting on first. On the host itself, 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, zypper --non-interactive install alpamon-pam on openSUSE and SLES. See installation.
  • The package is present but /etc/sudoers.d/alpacon is gone: the action does nothing on a host already at the current version, so reinstall from the shell—apt-get install --reinstall -y alpamon-pam or yum reinstall -y alpamon-pam—to restore the file.
  • 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.

sudo fails or asks for the root password on openSUSE or SLES

openSUSE and SLES need alpamon-pam 1.1.5 or later. Earlier versions fail in one of three ways:

VersionWhat you see
1.1.2 or earlierzypper install alpamon-pam stops with nothing provides 'jansson'.
1.1.3Every sudo on the server fails with unable to load /usr/lib/sudo/sudo/alpacon_approval.so.
1.1.4sudo asks Alpacon users for the root password, which they don’t have.

Upgrade from a root shell on the server with zypper --non-interactive install alpamon-pam. If sudo itself fails (1.1.3), open the root shell another way, such as su - with the root password or the server’s console. When the server’s detail page offers Install or upgrade alpamon-pam, it does the same upgrade through the agent and works even when sudo fails.

Servers registered with an earlier openSUSE/SLES install command may also have /etc/sudoers.d/alpacon-wheel. Alpacon users don’t need it, so you can delete it unless an account you manage yourself, such as the user an Ansible play connects as, relies on it.

”Alpacon denied this sudo command”

When a sudo refusal includes an error code, the terminal prints:

Alpacon denied this sudo command (SUDO_NO_WORKSESSION_POLICY).

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

The workspace setting is Sudo through Alpacon in Access rules. For session scope, add Sudo on the session page or with alpacon work-session update --scope. For policies, follow the sudo command pattern rules.

CodeMeaningWhat to do
SUDO_SESSION_MISSING#Alpacon could not match the sudo request to an open session or its command.Run sudo inside an approved work session or an interactive Websh session, then retry.
WORK_SESSION_SCOPE_NOT_ALLOWED#The work session does not include sudo.Add sudo to the session scope, obtain approval if required, then retry. When using --scope, include every scope the session needs because the flag replaces the list.
SUDO_COMMAND_TOO_LONG#The command is too long to record for review.Shorten the command, or put it in a script and run the script.
SUDO_SYSTEM_USER_NOT_FOUND#Alpacon has no record of the server account running sudo.Connect as an account listed for the server, or ask an administrator to check the account.
SUDO_ACCOUNT_BOUND_TO_APPLICATION#The Websh account is linked to an application and cannot receive sudo access in the terminal.Run the command with alpacon exec using the application's service token.
SUDO_NO_ACCOUNTABLE_ACTOR#No active user can be identified as responsible for this sudo request.Link the server account to a user, or use a work session with an active user as its assignee.
SUDO_STEP_UP_UNAVAILABLE#The deployment does not use Auth0, so it cannot complete the required MFA check.Use a work session with a sudo policy whose approval takes the place of MFA.
SUDO_PRESENCE_REQUIRED#The command needs a recent MFA check.Complete MFA with your configured method, then run the command again.
SUDO_COMMAND_NOT_AUTHORIZED#The command has no recorded user to authorize sudo for it.Run the command from a session you signed in to.
SUDO_POLICY_MFA_REQUIRED#The matching sudo policy requires MFA, but the command has no interactive terminal for it.Run it in Websh, or ask an administrator for a work-session sudo policy whose approval takes the place of MFA.
SUDO_NO_WORKSESSION_POLICY#The work session has no sudo policy matching this command.Add a matching pattern with work-session update --sudo. Match the entire command without its sudo prefix; * is the only wildcard.
WORKSPACE_SUDO_WITH_MFA_DISABLED#The workspace does not allow sudo through Alpacon.Ask a Superuser to enable workspace sudo.
SUDO_APPROVAL_REQUIRED#The command needs a person's approval, and a request was opened.Run the same command again once it is approved.
SUDO_APPROVAL_PENDING#The approval wait ended, you stopped waiting with Ctrl+C, or the MFA check was not completed in time. The request stays open.Run the same command again once it is approved.
SUDO_APPROVAL_ALREADY_WAITING#The same sudo command is already waiting for approval in another terminal.Use the terminal that is waiting, or press Ctrl+C there first.
SUDO_APPROVAL_REJECTED#An approver rejected the request, or it was withdrawn.The command did not run. Ask the approver why, or request it again with a clearer reason.
APPROVAL_NO_OTHER_APPROVER#Nobody but the requester can approve this request.Ask a Superuser to add another approver or an auto-approve rule.
SUDO_NO_AUTHORITY#No sudo permission or policy covers the request. In Enforce, an administrator approval request is opened and the terminal waits when possible. In Advisory, it is refused immediately without an approval request.In Enforce, rerun once approved. In Advisory, ask an administrator for standing sudo access.
SUDO_TARGET_OTHER_PERSON#The command switches into another person's account, which is always blocked.Use your own account or a shared account.
SUDO_TARGET_UNPARSED#Alpacon cannot read which account the command switches into.Name the target account explicitly, for example sudo -u deploy whoami.
SUDO_INTENT_DEVIATION#The command does not match the work session's purpose, and an approval request was opened.Wait for approval, or request a work session that describes this work.
SUDO_RISK_DENIED#The workspace's access rules block the command, or it was judged too risky.Ask a Superuser to review the access rules.

For the approval messages and what happens while the terminal waits, see Waiting for approval. For immediate refusals, see When nothing waits. For a deployment without Auth0, see Deployments without Auth0.

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

Messages without a code

These messages have no code to look up. The table quotes the first sentence of the temporary-unavailability message.

MessageMeaningWhat to do
Alpacon denied this sudo command.The command was refused without a code. This includes local sudo blocked outside Websh or alpacon exec.For local sudo, run the command in Websh or ask an administrator to review the Sudo outside the web terminal setting. For a command run through Websh or alpacon exec, check the Denied tab of Privilege elevation in the web console.
Alpacon sudo authorization is unavailable; command denied.The agent did not return an authorization result before the request failed or timed out.Check that alpamon is running (systemctl status alpamon), then check the server connection and agent logs before retrying.
Alpacon authorization is temporarily unavailable (the agent is not accepting connections); command not authorized.The agent is temporarily unable to accept an authorization request. This is not a policy refusal.Wait a moment, then retry.
Alpacon sudo authorization returned an invalid response; command denied.The authorization reply could not be read.Ask an administrator to check the agent logs.
Alpacon could not determine the sudo command; denied.PAM could not identify the command to authorize.Check the command and ask an administrator to inspect the agent and PAM logs if it repeats.
Alpacon could not determine the sudo target user; denied.PAM could not identify the target account.Specify the target account clearly, for example sudo -u deploy whoami.
Alpacon could not encode the sudo command; denied.The command could not be encoded for authorization.Check that the command uses valid UTF-8 text.
Alpacon could not encode the sudo identity; denied.The account information could not be encoded for authorization.Ask an administrator to check the account names and their encoding.

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. On Linux servers running Alpamon 2.0.2 or later, removing or changing alpamon-pam directly on the host is reflected after the next agent report. With older agents, the displayed version can remain after a removal 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, openSUSE/SLES
rpm -q alpamon-pam
Last updated: