fix: the shell runs as the console account of each member of admins, a local account or the user's own POSIX account in the directory, which also signs in with SSH and sudo, instead of one web.shell_user.

ADR.md

@@ -905,8 +905,9 @@ xterm.js expects as a WebSocket. The web service runs in a sandbox (`NoNewPrivil
 in a browser should not be. A stolen session cookie or access token alone must not give a shell.
 
 Decision: `/shell` of the web service is off until `web.shell` is set on the router; the Router
-Manager cannot set it. The shell runs as `web.shell_user`, a system user other than root, which
-reaches root through its sudoers entry. `POST /shell` signs the user in again with the password
+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. The WebSocket of RFC 6455 is implemented on the standard library inside the
 web service's `http.server`, server side only, without extensions. `systemd-run --pty` starts the
@@ -917,7 +918,34 @@ Manager checks the session and the WebSocket's origin, and relays the bytes to t
 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; a session alone cannot. 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 `web.shell_user`. 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.
+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
+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.
+
+## ADR-34: Console login maps an administrator to a POSIX account
+
+Context: A shell, SSH and sudo need a POSIX account. One shared system account for every
+administrator hides who did what and shares one set of rights. The administrators are users of
+the router's directory, with their passwords, TOTP tokens and lockout there; a second set of
+local accounts would duplicate them. slapd listens on its local socket only. SSSD authenticates
+only over TLS or LDAPS and has no `ldapi://`; nslcd talks `ldapi://` and checks a password by
+binding as the user.
+
+Decision: Console login is a property of a member of `admins`, `vpnRouterConsoleLogin`, that
+only root on the router sets, as for the group `admins`. It runs the console as an existing local
+account (`vpnRouterConsoleAccount`), or as the user's own POSIX account: the user's entry becomes a
+`posixAccount` with a uid from 20000 up and the local group `vpn-router-console` as its group.
+nslcd serves the POSIX accounts with console login on, and PAM checks their passwords with a bind,
+so slapd's otp overlay and password policy apply as for the Router Manager: the password followed
+by the code, and the lockout. Members of `vpn-router-console` get sudo with that password. SSH
+accepts it only while `ssh.ldap_login` is set, in a `Match Group` drop-in of sshd. Switching console
+login off keeps the `posixAccount`, hidden by nslcd's filter, so the uid and the home stay the
+user's; leaving `admins` switches it off.
+
+Consequences: Each administrator's shell, SSH session and sudo run as the administrator, logged
+under the administrator's name. The directory becomes part of the system's name service through
+nslcd, and the system knows only the accounts with console login on. A user enrolled for TOTP types
+the code after the password at the SSH and sudo prompts. Homes are created at the first login and
+are not removed with the user. A password is changed through the directory, not with `passwd`.