seikan-server has a built-in web console at /_admin on the admin host (e.g. https://admin.example.com/_admin) — no separate install, no extra port. It's the front end to the admin API, and it's where administrators are created and client keys are issued.

First-time setup

A new server has no accounts, so the first visit to /_admin shows a two-step wizard instead of a login form:

1. Setup key — the server prints this when it starts, and keeps it in <state-dir>/setup-key. Lost the output? Run seikan-server setup-key on the server host. In a container you'd normally supply it yourself as SEIKAN_SETUP_KEY.
2. Administrator account — pick a username and a password (at least 8 characters). You're signed in immediately.

The setup key authorizes exactly this, and only until it works: once an administrator exists the endpoint refuses (409) and a generated key file is deleted. Replaying it can't create a second account.

Logging in

After setup, /_admin asks for the username and password. That starts a session stored server-side, carried by a browser cookie, lasting 30 days of inactivity. Log out from the sidebar to end one early; restarting the server ends all of them.

Forgotten password? There's no email reset — recover on the server host with seikan-server user passwd <username>. Adding further administrators is seikan-server user add <username> (the server supports several; the UI doesn't manage them yet).

What's there

• Client keys — issue and revoke the keys seikan clients authenticate with. A new key's raw value is shown once; copy it before navigating away. Revoking a key deletes the frontends it owns and closes their tunnels.
• Requests — machines that ran seikan init without a client key and are waiting to be let in. See below.
• Clients — every configured frontend, with live online/offline status (whether a tunnel client is currently connected), type, domain or port, and certificate status.
• Guidance — the install, seikan init, seikan add and seikan start commands, prefilled with this server's real admin host (and, if you just created a client key in the same session, that key's real value).

Approving a client

Instead of issuing a key and getting it onto the machine somehow, run seikan init --server <admin-host> there with no --api-key. It prints a confirmation code and waits. The request appears under Requests with that code, the hostname the client reported, and the address it came from; approve it and the waiting client picks up its own client key and carries on.

Check the code before approving. It is the only thing that distinguishes the machine in front of you from another request that arrived at the same moment — the sidebar count tells you how many are waiting. Approving is quick; approving the wrong one hands a stranger a client key.

Requests expire after 15 minutes, and nothing is created by one until you approve it: the key is minted when the client collects it, so an approval nobody picks up leaves no credential behind. Deny is there for a request you don't recognise; the client is told and stops waiting. If the operator interrupts seikan init and runs it again, it resumes the same request with the same code rather than adding a second row.

Notes

• Your password never leaves the admin UI. What ends up on a client machine is a client key, which can manage only its own frontends — it can't sign in here, and it can't issue more keys. With the approval flow, no credential travels between machines at all.
• The setup and login pages are reachable without authentication (they have to be), but every actual endpoint they call requires a valid session or client key.
• Like the rest of the admin API, /_admin only ever responds on the admin host — it's unreachable on any frontend domain.