Asterisk AMI session authentication, Login, Logoff and Challenge

Define the listener, transport and session boundary

Record the running Asterisk branch and maintenance release, server identity, manager listener address and port, transport protection, client source, manager username and connection time. Treat each TCP or HTTP manager connection as its own session and keep secrets out of logs and captures.

A reachable manager port proves only a network path to a listener. It does not authenticate the server to the client, authenticate the user, establish permissions or prove that a later action belongs to the expected session.

Choose the documented Login field set

Login accepts Username, an optional AuthType, either the corresponding Secret or Key, an optional Events selection and a unique ActionID. The current generated reference documents plain as the default authentication type and MD5 as the alternative. The username and secret originate in manager.conf.

Do not send both credential forms speculatively. Preserve which field set the client actually used, the raw response and the session that received it, while redacting credential material.

Treat Challenge as an MD5 exchange, not a secure channel

The generated Challenge action accepts only AuthType: MD5. The returned challenge is combined with the manager secret to produce the lowercase hexadecimal Key used by Login. Record the action and response boundaries without retaining reusable secret material.

This challenge exchange is not transport encryption, server identity proof, a VPN or an authorization policy. The official network-security guidance says the manager interface should be used in a safe environment or protected with SSH or another VPN solution, with manager ACLs controlling network access.

Separate login event selection from authorization

The Events field on Login can request all events, no events or selected event classes. That session mask remains separate from the manager user's read classes, configured or dynamic filters, transport delivery and client parsing. A quiet connection is not automatically an authentication failure.

Write classes govern action categories. Successful authentication does not grant every action, and a requested event class does not override the account's read authorization.

Use Logoff as an explicit current-session action

Logoff ends the current manager session and returns its supplied ActionID. Keep an explicit logoff, a peer closing the socket, a network reset, a server restart and a client timeout as different termination evidence. A disconnected socket alone does not identify which one occurred.

After reconnect, assign a new session identity and new request identifiers. Do not merge pre-disconnect responses or event sequences into a new connection merely because the username is unchanged.

Verify authentication, permissions and operations in order

First establish the expected server and protected path, then the exact login response, then the commands available to that user, then the requested event mask and delivery controls, and finally one authorized operational action with its own completion boundary. These checkpoints prevent a transport success or login acknowledgement from standing in for service behavior.

Use least-privilege read and write classes, source ACLs, credential rotation and bounded reconnect behavior appropriate to the deployment. No PBX, manager configuration, credential, ACL, socket, session, request, response, event, channel, packet, media stream or live call was inspected or tested for this guide.

Bind core queries to one authenticated session

Use fresh identifiers and preserve the current session when collecting core status and settings; do not merge responses across reconnects.

Keep queue snapshots inside one manager session

The queue-snapshot diagnostic rejects response items and completion evidence that cross reconnect boundaries.

Keep mailbox evidence inside one current manager session

The mailbox-query diagnostic binds target, mailbox, ActionID and raw response to the current connection.

Keep voicemail inventory inside one evidenced session

The voicemail-user diagnostic binds action, ActionID, module and frames to one connection.

Keep AMI session evidence separate from security-log custody

An AMI authentication outcome may produce security evidence, but AMI response, session lifecycle, res_security_log output and downstream enforcement remain separate. Use the security-event diagnostic.

Bind every variable action to one manager session

The AMI variable diagnostic retains connection identity, ActionID, response and event scope.

Bind each AstDB action to one authenticated session

The AMI AstDB diagnostic retains connection identity, ActionID, response and namespace evidence.