Rotate Linux passwords from the vault that stores them

The gap everyone lives with

Every vault knows the root password. Almost none can change it.

A password manager stores the credential; changing it on the machine is someone's manual task, so it happens once, at build time, and then never again. LAPR closes that loop — it shipped in 3.2.2, in the open-source server, with no extra licence.

Rotation is scheduled, then postponed

Changing a service account password by hand means an outage window, a runbook and someone available. It slips, and the credential quietly ages into a compliance finding.

The vault and the machine drift apart

Someone rotates on the server and forgets the vault, or edits the vault and never touches the server. Now nobody trusts either, so nobody rotates anything.

Offboarding leaves shared logins behind

The leaver report tells you which shared accounts a departing engineer could reach. Acting on it means changing those passwords on dozens of hosts — which is exactly why it does not get done.

How a rotation runs

The server changes first. The vault records second.

The order matters more than anything else on this page. Teampass only ever stores a password the machine has already accepted, so the vault cannot end up holding a credential that does not work.

Stage 1
Read the current value

The item is decrypted server-side first. This proves the key chain works before anything is touched, and captures the previous password for the item history.
Stage 2
Generate from the policy

Length and character sets come from the rotation policy, and the result is filtered to be safe for chpasswd — no colon, no whitespace, no quotes or backslash.
Stage 3
Push it over SSH

One SSH session, one chpasswd call, through sudo -n when the account is not root. If the server refuses, nothing has changed anywhere.
Stage 4
Re-encrypt and fan out

The item is re-encrypted, every user's key is refreshed, the previous value is stored in the item history and connected browsers are updated in real time.

And when stage 4 fails? The account is marked in error with a manual resync required note, because the server already holds the new password. That case is stated loudly rather than swallowed — it is the one situation where a human has to intervene, and pretending otherwise would be worse than the outage.

Agentless

What you install on the target servers: nothing

No agent, no package, no port to open inbound, no configuration file to template out. LAPR is an outbound SSH session from the Teampass host, made with the phpseclib3 library already bundled with the application — there is no sshpass, no php-ssh2 extension and no call to exec() anywhere in the path.

Every SSH operation runs in a background task. Nothing blocks a web request, so a slow or dead host degrades a queue rather than a page.

Reachability from the Teampass host to the target SSH port
chpasswd present on the target — it is, on every mainstream distribution
An SSH account that is root, or has passwordless sudo for chpasswd
Teampass background tasks running — cron or the FPM trigger

The entire footprint on a managed host, root and non-root:

printf '%s:%s\n' 'svc-deploy' '••••••' | chpasswd

printf '%s:%s\n' 'svc-deploy' '••••••' | sudo -n chpasswd

# discovery, when you ask for it
getent passwd

The SSH credential itself is an ordinary Teampass item. LAPR reads it server-side at connection time — it is never typed into a form, never sent to a browser and never duplicated into a second secret store.

Guard rails

A tool that changes root passwords has to fail safely

LAPR holds a reusable, privileged credential for every server you enrol. The design assumes that is dangerous, and constrains it accordingly.

Host key changes block the rotation

The fingerprint is trusted on first use at enrollment and verified before the credential is transmitted. A mismatch aborts — it is not downgraded to a warning, because the thing at risk is a root password.

Retry, then suspend — never hammer

Transient connectivity failures are retried on a delay you set, up to a maximum you set. Then the account suspends and waits for a human. Everything else — bad credentials, missing privilege, misconfiguration — fails once and stops.

An audit log that cannot leak

Every enrollment, check, rotation, retry, suspension, pause and reset is recorded with its actor and outcome. The fields are a whitelist, so a password cannot reach the log even by accident.

Separated from administration

Administrators enable and configure LAPR. Operating it requires the distinct Can manage LAPR permission, and folder rights apply on top — you manage the accounts whose items you can already write.

Off by default, and fenced in

The module ships disabled and does nothing until an administrator turns it on. An optional allowlist restricts which hostnames LAPR may reach at all, connection attempts are rate limited, and managing the Teampass host itself is blocked unless it is deliberately, explicitly enabled.

No parallel secret store

Rotated passwords live in the same items, under the same AES-256-GCM object keys and the same per-user key wrapping as everything else in your vault. LAPR adds a workflow, not a second place for secrets to sit.

The encryption and key distribution model

Inside the vault

A managed item tells you it is managed

The worst outcome for a rotation tool is a well-meaning colleague editing a password by hand and desynchronising the vault from the machine. Teampass makes that impossible rather than discouraged.

Badges in item lists, search results and the item header mark managed items and SSH credential items
On a managed item the login and password are read-only; label, URL, description, tags and custom fields stay editable
Deleting an item a managed account or endpoint still references is refused
Moving one into a personal folder is refused — the server has to be able to read it
The same rules apply to bulk actions and to the REST API, which answers 409; bulk operations skip linked items and tell you how many
Automatic changes appear in the item history as LAPR system, manual ones under the name of whoever asked

Enforcement lives in the handlers, not the browser. Bypassing the interface with a script gets you the same refusal, which is the only version of this guarantee worth having.

An SSH credential item stays editable on purpose — it is the recovery path when a connection password is changed outside Teampass. The interface warns that editing it does not change anything on Linux.

Operating it

Day to day

Reusable rotation policies

Frequency from 1 to 3 650 days, length from 8 to 128, the character sets you allow, and an optional rotate-on-enrollment so a newly managed account gets a password nobody has ever seen. Three presets ship ready to use; preview a sample before you save your own.

Discovery instead of typing

Ask an endpoint what accounts it has: LAPR reads getent passwd and lists root plus real login accounts, skipping system accounts and anything shelled to nologin. You pick which ones to manage — it never creates an item on your behalf.

Scheduled, checked and pausable

The scheduler rotates what is due. Enrolled endpoints are re-checked periodically — reachability, OS, and the privilege probe — and a recovering host is retried sooner than the normal cadence. One endpoint going into maintenance can be paused, with a reason, without disturbing the state or the due dates of its accounts.

Health and statistics, without SSH

System Health → LAPR reports scheduler and worker state, queues, overdue and suspended accounts, and referential problems. Statistics → LAPR shows rotation volume, success rate, failure categories and policy adoption. Both are passive reports — opening the page never opens a connection.

Honest scope

What LAPR is not

This is one job done properly, not a privileged-access platform. Knowing the edges before you deploy it is worth more than a longer feature list.

Local Linux accounts only

Windows accounts, directory accounts, database users, network appliances and cloud IAM identities are out of scope. If your estate is mostly one of those, LAPR is not the reason to choose Teampass.

Not session brokering

LAPR changes passwords. It does not proxy your SSH sessions, record them, or hand out short-lived access — the things a full PAM product exists to do.

Managed items must be shared, not personal

The server reads the item as itself in order to rotate it, and personal folders deliberately prevent that. Managed accounts and SSH credentials live in shared folders.

It concentrates privilege — plan for it

The folder holding your SSH credential items is a crown-jewel folder: whoever can read it holds root on the estate. Restrict it hard, and treat that decision as part of deploying LAPR.

Where this sits

Normally you would buy a second product for this

Rotating the credentials of the machines themselves is privileged-access territory, sold separately, licensed per host, and deployed alongside the password manager you already run. Teampass does the narrow, useful part of it from the vault that already holds those credentials — in the open-source server, with no licence key and no per-host cost.

Compare Teampass with the alternatives

None of the self-hosted alternatives on our comparison page rotate local Linux account passwords. That is a deliberate claim, listed as a row in the table, and we would rather you check it than take our word for it.

Getting started

From nothing to a first rotation

Enable and fence the module

Operations → LAPR settings. Turn the module on, switch on the hostname allowlist, and grant Can manage LAPR to the people who will operate it.
Enrol one endpoint

Host, port, SSH user, and the Teampass item holding its credential. Test connection records the host key, collects the OS and proves the account can actually change a password.
Manage one account, then rotate

Attach an existing item to that endpoint, pick a policy, and use Rotate now. Watch it in the history, then let the scheduler take over.

Every setting, error code and failure mode is documented in the LAPR documentation. Start on a disposable VM, not on the box that runs your vault.

Questions

Straight answers

Do I have to install anything on the servers?

No. LAPR is agentless. It opens an SSH session with a credential you already store in Teampass, runs chpasswd, and disconnects. There is no daemon, no package, no scheduled job and no configuration file on the target.

What does the SSH account need to be able to do?

Either be root, or hold passwordless sudo for chpasswd. Teampass probes this during enrollment and refuses the endpoint if neither is true, rather than accepting it and failing on every future rotation. When the right is missing, the check screen shows the prerequisite and the sudoers line for the operating system it detected.

What happens if a server is unreachable?

Only transport failures — timeout, connection refused, host unreachable, lost connection — are retried, up to the configured maximum and spaced by the configured delay. After that the account is suspended and waits for a human to use Reset & resume. Authentication, privilege, host key and configuration failures stop immediately, because retrying cannot repair them.

What if the SSH host key changes?

The rotation is blocked. LAPR connects with a reusable, privileged credential, so a changed host key is treated as a man-in-the-middle signal rather than a note in a log. Verify the server, then trust the new key explicitly.

Does it work on Windows, Active Directory or databases?

No. LAPR rotates local Linux accounts over SSH, and nothing else. Windows accounts, directory accounts, database users, network appliances and cloud IAM identities are outside its scope. It is deliberately one thing done properly rather than a thin layer over everything.

Can a Teampass administrator rotate passwords?

No, and that is on purpose. Administrators enable and configure the module; operating it needs the separate Can manage LAPR permission, which is held by non-administrators, and folder rights still apply on top — an operator can only manage accounts whose item folder they can write to.

Is a password ever written to a log?

No. The LAPR audit log records operational metadata only, on a whitelist — action, endpoint, account, error code, actor, timestamp. The same holds for the failure alert emails and for the System Health JSON export.

What happens if I switch the module off?

Everything is released. Linked items behave like ordinary items again — no badge, no read-only field, no blocked delete or move — and pending tasks are cancelled. Endpoints, accounts and audit history stay stored and pick up where they left off when you switch it back on.

Does LAPR create accounts or vault items?

Neither. It manages the password of a Linux account that already exists, recorded in a Teampass item you already store. Discovery lists what is on the server; you decide what gets managed.