Menu AuthGuardHelp centre
Portuguêsauthguard.pt

Administrators · Linux sign-in

Linux sign-in with a second factor: the PAM module and the agent

  • 2 min read
  • SaaS · Self-hosted · Linux

Not available yet

This article describes a feature in development. You cannot use it yet; the article is here to help you plan.

Linux computers and servers will get the same second factor as Windows: after the Linux password, the person approves on the phone or types a code. It is made of two pieces: a PAM module (pam_authguard.so) that Linux calls at sign-in, and an agent (authguard-agentd) that talks to the service.

Is it available?

Not yet. The module and the agent are built and tested on Debian, but the service does not yet accept Linux computers, and the installation packages for each distribution are still to be published. This article describes how it will work, so you can plan a pilot.

What does it protect?

Linux serviceWhen
Console and graphical sign-in, screen unlockAt the computer
SSHRemote sign-in
sudo, su and pkexecRaising privileges

The module runs after the password module, so a wrong password never reaches the phone. Services it does not know are left alone; a custom service can name its scenario with the scenario= argument.

How is a computer enrolled?

  1. Create an install token under «Manage» › «Computers», as for Windows. See Install tokens.
  2. Install the agent and run authguard-agentd enrol --origin <organization address> --token-file <file>. The token works once.
  3. The agent writes /etc/authguard/agent.toml, then gets its settings and branding from the service.
  4. Add the module to the PAM stacks you want to protect, after the password module.

One package serves every organization. Computers never count as licences. A computer that was never enrolled is never affected by the module.

Where are the keys kept?

When the computer has a TPM 2.0 chip, the agent seals its keys to it with systemd-creds; otherwise it keeps them in files only root can read. Only root processes can ask the agent for a sign-in decision; screen lockers can only unlock their own user's session at the console.

What happens without a network?

  • At the console, people who already signed in online use their offline code, or the support challenge (typing R).
  • Remote sign-in (SSH) is refused while offline.
  • Break-glass accounts sign in at the console with the password alone, and the event is reported later.

And if the agent stops?

By default the module fails closed: only break-glass accounts and the support challenge work at the console. For a staged rollout you can set fail=open, which lets the password alone through while the agent is down. Remove it once the pilot is stable.

Article referencead-linux-agentquote it to support to identify this article. Checked against the product at commit 78c33b39.