---
title: "PAM and sudo issues"
description: "Troubleshoot Alpacon PAM and sudo errors, including sudo-rs terminal prompts and missing sudoers rules. Check denied commands and PAM versions before retrying."
---

> Full documentation index: https://docs.alpacax.com/llms.txt

# PAM and sudo issues

Troubleshooting guide for [sudo with MFA](/use/work-sessions/terminal/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](/use/work-sessions/terminal/sudo-with-mfa/#compatibility-with-sudo-rs) hosts (Ubuntu 25.10 and later), a `sudo` command run without a terminal—for example through `alpacon exec`—can fail with:

```text
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 line | Meaning |
|----------|---------|
| `No session found for PID` | The `sudo` did not come from a tracked Alpacon session. Run it inside an approved [work session](/use/work-sessions/) or an interactive Websh session. |
| `sudo_approval response timeout` | Alpacon 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_code` | The command was explicitly denied. Look up the code in ["Alpacon denied this sudo command"](#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:

```text
# 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](/use/servers/manage/#agent-card) or run `alpacon agent install-pam <server>` with the CLI. Both send the [`install_pam` action](/reference/api/servers/servers/#agent-actions), 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](/use/servers/register/install/#linux).
- **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](/use/policies/server-access/) 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:

| Version | What you see |
|---------|--------------|
| 1.1.2 or earlier | `zypper install alpamon-pam` stops with `nothing provides 'jansson'`. |
| 1.1.3 | Every `sudo` on the server fails with `unable to load /usr/lib/sudo/sudo/alpacon_approval.so`. |
| 1.1.4 | `sudo` 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:

```text
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](/use/policies/server-access/). For session scope, add **Sudo** on the session page or with [`alpacon work-session update --scope`](/reference/cli/work-session/update/). For policies, follow the [sudo command pattern rules](/reference/cli/work-session/create/#sudo-command-patterns).

For the approval messages and what happens while the terminal waits, see [Waiting for approval](/use/work-sessions/terminal/sudo-with-mfa/#waiting-for-approval). For immediate refusals, see [When nothing waits](/use/work-sessions/terminal/sudo-with-mfa/#when-nothing-waits). For a deployment without Auth0, see [Deployments without Auth0](/use/work-sessions/terminal/sudo-with-mfa/#deployments-without-auth0).

Find the console messages for [`sudo_session_missing`](/reference/error-messages/#sudo_session_missing), [`sudo_no_worksession_policy`](/reference/error-messages/#sudo_no_worksession_policy), and [`workspace_sudo_with_mfa_disabled`](/reference/error-messages/#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.

| Message | Meaning | What 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](/use/audit/events/sudo/#granted-and-denied) 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
```

Source: https://docs.alpacax.com/use/work-sessions/terminal/troubleshoot-sudo/