Sign in and API keys
People sign in with a username and password. Scripts use an API key in the Authorization header. Both are scoped the same way.
Signing in
The console is at /ui. The first superadmin is admin; its password comes from the hub's ADMIN_PASSWORD setting. If that is not set and the admin has no password yet, the hub generates a temporary one at start-up and prints it in its log, and asks for a new one at first sign-in.
Passwords and sessions
- Passwords are stored as salted scrypt hashes.
- A session is an HttpOnly, SameSite=Strict cookie, Secure over HTTPS; 12 hours idle, 30 days at most.
- Five failed sign-ins for the same address and username lock that pair out, doubling from 60 seconds. Every sign-in, failure and lockout is in the audit trail.
- Change your own password from the top strip. Changing it signs out your other sessions.
- A temporary password issued by an admin must be changed at the next sign-in and signs out any existing sessions of that user.
API keys
Every user has an API key of the form bek_…, shown once at creation and rotatable from Users. Send it as Authorization: Bearer bek_…. A key sees exactly what its user sees. The header wins over a session cookie when both are present.
curl -H "Authorization: Bearer bek_…" https://hub.[yourdomain]/meForgotten password
A company admin or superadmin issues a temporary password from the user's row (reset password). There is no self-service reset, on purpose: the people who can sign in are the people who can approve changes on machines.
Try it on one machine first.
The install line takes a minute. Uninstall the agent and you are out.