Act in an account
You can open the account panel as any account, without its password, to see what the holder sees and do what they can do. The panel calls this impersonation, records it as such, and keeps it out of the holder's view of their own activity.
Sign in as an account
Impersonate, in the General Information section of the account's page, opens a new window signed in to the account panel as that account. On the command line:
elpanctl account impersonate <username>
prints a URL. Open it in a browser and you are signed in. The URL carries a token that is valid for two minutes and works once; a second use, or a late one, is refused.
The session is a full session of the account, with the account's permissions and its view of the panel. It asked for no password and no second step, so when the panel would normally ask the holder to confirm their identity before a sensitive action (sudo mode), it does not ask you: you know none of the account's credentials and need none. The one exception is removing the account's password, which needs a passkey of the account there and then; the page says so instead of offering it.
Nothing on the admin app's Web Applications screen changes a site: a plugin update, the permission fix and the opt-in to automatic updates are done in the account panel. To do one for a holder, impersonate the account; see Web Applications.
What is recorded
An impersonated sign-in is a login row in the account's auth log with the
method impersonation, and every row the session causes afterwards is
marked as caused through an impersonated session. Who sees those rows
depends on where they look:
| Where | Impersonated rows |
|---|---|
| Accounts › Auth Log (the admin app) | Shown and flagged. See Auth Log. |
| The account's Account Activity page | Left out. The holder sees their own activity, not yours. |
| The account's own auth log through its API and MCP tools | Included; the sign-in's method reads impersonation. |
| The server's syslog | Every row is also written there. |
The account's devices are not told of an impersonated sign-in: the sign-in alerts the holder gets for a password or passkey sign-in stay quiet. A pending request for help signing in is not closed by it either, since it is not the holder's own sign-in.
The account docs tell holders that their provider can sign in as them, and that the activity page does not show what such a session does: Account Activity.
End every session of an account
elpanctl account invalidate <username>
rotates the account's security stamp: every signed-in session of the account, every remember-me cookie and every MCP token stops working at its next request. It prints nothing, and does nothing for a username that does not exist.
Use it when a session of the account may be in the wrong hands and you do
not want to change its credentials. A credential reset (Reset
credentials, account reset, account reset-password) rotates the stamp
too, so after one of those nothing more is needed; see
Accounts. A suspension ends
the account's sessions as well; see
Suspend, terminate and delete an account.