Manage your passkeys, and get back in if you lose them
A passkey is the node’s only login, on every bind including loopback — there is no local-access shortcut. So the way back in matters. All three need the node running; they talk over the admin unix socket, whose permissions are the host’s.
hdtp-gateway passkey list # id, tag, ownerhdtp-gateway passkey remove -id <id> # refuses the last onehdtp-gateway passkey reset-wizard # a one-time link that re-opens registrationreset-wizard is the recovery path. It prints a URL valid for 24 hours and
usable once:
one-time setup URL (24h, single use):http://localhost:8080/setup?token=b0527dbe01e36eed2ef51a576b4a2e34Open it and register a new passkey. It adds one and removes nothing, so a device you still have keeps working. This is the only thing that re-opens the wizard once a passkey exists — reaching loopback does not, and neither does a leftover first-run token, or any local process could quietly register itself as an owner.
That makes shell access on the host the root of trust for recovery, which is the honest trade: there is deliberately no online recovery path, no email reset, nobody to ask. Register a second passkey on another device before you need one.
Running in Docker? Prefix it:
docker compose exec hdtp-gateway hdtp-gateway passkey reset-wizard. And sign in athttp://localhost:<port>, not127.0.0.1— a loopback portal presents itself aslocalhostbecause an IP is not a valid WebAuthn relying-party ID, so that is the name your passkey is bound to.