Sudo bridge

When you SSH into a device through Meshr, the destination shell is already proof of who you are — your SSH user certificate carries the cert principal that matched your identity in the controlplane. On Linux, the sudo bridge carries that proof one layer further so sudo skips the password prompt for processes that descend from that mesh-authenticated shell. Sudo invocations from any other path — a local console, an SSH key outside Meshr, a cron job, a container — still hit the standard password challenge.

Default on every fresh install. No configuration to flip on; the DEB postinstall wires it up.

How it works

┌────────────────────────────────────────────────────────────┐
│ You: meshr ssh ubuntu@build-server                         │
│      ubuntu@build-server:~$ sudo apt update                │
└─────────────────────┬──────────────────────────────────────┘
                      ▼
              /etc/pam.d/sudo
              auth [success=1 default=ignore] pam_meshr.so
              auth required                    pam_unix.so
                      │
                      ▼
              pam_meshr.so → /run/meshr/sudo-broker.sock
                      │
                      ▼
              meshr-daemon broker
               ✓ Process descends from a registered mesh shell
               ✓ Cert is still valid (not expired, not revoked)
               ✓ Principal in the cert matches the calling user
               ✓ Access rule allows passwordless sudo
                      │
                      ▼
              PAM_SUCCESS → sudo runs the command, no password

For any of those checks that fails, the PAM module hands back control to pam_unix.so and sudo prompts for a password just like before.

Supported platforms

OS	Supported
Debian 11+	✅
Ubuntu 22.04+	✅
Armbian (OrangePi, RPi, etc.)	✅
RHEL / Fedora / Rocky	🛠 packaging in flight
Alpine	🛠 packaging in flight
macOS	🛠 design in flight
Windows	n/a (no sudo equivalent)

Defaults

A fresh agent install on a supported Linux distro:

Drops pam_meshr.so into the canonical PAM library path for the device's architecture
Adds one line to /etc/pam.d/sudo above the existing pam_unix.so auth line
Validates the resulting stack with visudo -cf and rolls back the edit if validation fails — sudo never gets left in a broken state by the install

Existing SSH access rules in the controlplane flip to passwordless sudo on the Cloud v0.6.22 upgrade (the migration back-fills every row); rules created later default to passwordless.

Opting out

At install time

sudo MESHR_NO_SUDO_BRIDGE=1 apt install meshr

The .so still gets staged for later activation, but /etc/pam.d/sudo is left untouched. Flip it on later with:

sudo meshr ssh enable-sudo-bridge

At runtime (one device)

sudo meshr ssh disable-sudo-bridge

Removes the pam_meshr.so line from /etc/pam.d/sudo. Re-enable the same way (enable-sudo-bridge).

Per access rule (dashboard)

Cloud v0.6.23+ surfaces a "Passwordless sudo via mesh" toggle in the SSH access rule editor. Open Dashboard → SSH → Access rules, click any rule, flip the switch. The list view shows a green sudo pill next to recording so you can audit which rules currently allow the bypass at a glance.

Per access rule (CLI / API)

The CLI mirrors the dashboard toggle for scripted / SSH-only workflows:

# List every rule with current sudo state
meshr ssh policy list

# Force password prompt on a specific rule
meshr ssh policy disable-sudo <rule-id>

# Turn it back on
meshr ssh policy enable-sudo <rule-id>

The CLI uses your daemon's current session, so you must be signed in as an org admin on the device you run these from. Devices apply the new policy on their next heartbeat (~60 seconds).

Direct API access is also available for automation:

curl -X PATCH https://api.meshr.to/api/v1/admin/ssh/rules/<id>/sudo-policy \
     -H "Authorization: Bearer <admin-token>" \
     -d '{"sudo_passwordless": false}'

When the bridge says no

The PAM module falls through to the standard password prompt whenever any of these are true:

The agent is not running, or the /run/meshr/sudo-broker.sock socket is missing
Your shell doesn't descend from a Meshr-spawned SSH session (local console, non-Meshr SSH path, cron, systemd timer, etc.)
Your SSH certificate has expired, was revoked, or matches no registered session in the daemon's broker
Your access rule has sudo_passwordless = false
The calling user doesn't match the cert principal that opened the session (e.g. you su - root first and then run sudo)

In every failure mode sudo itself still works — you just get the password prompt you would have seen without the bridge.

What it does not do

It does not modify /etc/sudoers or /etc/sudoers.d/. The bridge sits entirely in the PAM auth stack.
It does not grant new privileges. The cert and the access rule decide who can SSH into which device as which principal; the bridge only changes whether the password prompt fires.
It does not record sudo sessions yet. Recording lands in a later release alongside the dashboard policy editor.

Troubleshooting

sudo apt update still prompts for a password from a mesh session. Check, in order:

ls /lib/$(uname -m)-linux-gnu/security/pam_meshr.so — the module is staged on supported architectures (x86_64, aarch64).
grep pam_meshr /etc/pam.d/sudo — the auth line is in the stack.
journalctl -u meshr-daemon | grep sudo-broker — daemon reports the socket listening at startup.
meshr ssh policy list and confirm the rule that matches the peer has SUDO yes.
From the mesh session, id should show the user the cert principal allows — if you su into a different user mid- session, the bridge stops applying.

Sudo says pam_meshr: meshr: broker unavailable. The daemon isn't running or just restarted. The line is informational; sudo still works through the password prompt. Once the daemon is back, the next sudo invocation flows through the bridge again.

I want to disable the bridge on every device the org has. Set MESHR_NO_SUDO_BRIDGE=1 in your fleet provisioning script before running the install, and the .so is staged but not wired into the PAM stack. Existing rules can be disabled in bulk via the API.

Audit events

Every sudo-bridge state change shows up in the activity feed at Warning severity so SIEMs can route it to the same destination as the rest of your sensitive admin actions:

Event	When it fires
`ssh_rule_sudo_enabled`	Admin flips the rule's `sudo_passwordless` to true
`ssh_rule_sudo_disabled`	Admin flips the rule's `sudo_passwordless` to false
`ssh_access_rule.created`	New rule (includes the initial sudo state in the payload)
`ssh_access_rule.updated`	Bulk rule edit through the standard PATCH

Each row records the actor, the rule, the target device(s), and the IP the change came from. A spike in ssh_rule_sudo_enabled across many devices in a short window typically means an admin just opened a fleet to passwordless mesh sudo — the kind of change worth reviewing alongside the activity feed's filters.

Roadmap

Cloud v0.6.24 — sudo_invoked audit events surfaced in the activity feed (per-invocation visibility, opt-in due to volume)
Agent v0.7.7+ — RHEL / Fedora / Alpine packaging
Agent v0.8 — macOS support via Authorization Services
Cloud v0.7+ — command-level allowlist UI; just-in-time approval; session recording

How it works​

Supported platforms​

Defaults​

Opting out​

At install time​

At runtime (one device)​

Per access rule (dashboard)​

Per access rule (CLI / API)​

When the bridge says no​

What it does not do​

Troubleshooting​

Audit events​

Roadmap​