feature: a shell opens with one of the user's passkeys in place of the password and the TOTP code.

ADR.md

@@ -908,8 +908,14 @@ Decision: `/shell` of the web service is off until `web.shell` is set on the rou
 Manager cannot set it. The shell runs as the console account of the signed-in user (ADR-34), so
 it is never root and each administrator's shell is the administrator's own; a user without
 console login gets none. `POST /shell` signs the user in again with the password
-and TOTP code and gives a one-time ticket valid 30 seconds; a WebSocket on `GET /shell` with that
-ticket gets the shell. Asking for the password and code at every opening of the page is tiresome,
+and TOTP code, or with one of the user's own passkeys (ADR-36), and gives a one-time ticket valid 30
+seconds; a WebSocket on `GET /shell` with that ticket gets the shell. A passkey with user
+verification is a possession and a PIN or biometric in one step and cannot be phished, so it is
+as good as the password and the code; `POST /shell/passkey` begins a proof bound to the signed-in
+user and its credentials, and python3-fido2 refuses an answer without the user-verified flag. The
+TOTP enrolment stays required with a passkey: the PAM login session of the shell, through the
+`pam_authz_search` of nslcd for a directory account, and sudo in it need it, and loosening that
+filter would let such a user log in over SSH with the password alone. Asking for the password and code at every opening of the page is tiresome,
 so within `web.shell_auth_timeout` minutes of the user's last sign-in or keystroke a ticket is given
 without them; the times are kept in the web service's memory only, so a restart asks again, and 0
 keeps the sign-in at every opening. The WebSocket of RFC 6455 is implemented on the standard library inside the
@@ -920,9 +926,10 @@ makes the terminal its controlling terminal so window sizes reach the shell. A s
 Manager checks the session and the WebSocket's origin, and relays the bytes to the router after
 both handshakes.
 
-Consequences: Who can sign in as a member of `admins` and knows the password and the current code
-can get a shell when the router allows one and the user's console login is on; a session alone
-cannot. The ticket travels in the URL and appears in request logs, used up. The shell's sessions
+Consequences: Who can sign in as a member of `admins` and knows the password and the current code,
+or holds one of the user's passkeys and unlocks it, can get a shell when the router allows one and
+the user's console login is on; a session alone cannot. A failed passkey proof is refused but not
+counted as a failed login, as with the passkey sign-in. The ticket travels in the URL and appears in request logs, used up. The shell's sessions
 show up as `vpn-router-shell-<id>` units and logind sessions of the console account. The shell's
 traffic is as protected as the Router Manager's: HTTPS to Caddy, plain HTTP on the internal
 network to the web service.