docs(coding-lane): Abschluss - SSH-Zugang zu Gitea, ein Schluessel statt acht Zugangsdaten

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/aufgaben/umbau-openchamber.md

@@ -333,3 +333,86 @@ git remote set-url origin http://192.168.178.153:3000/Hitonabi/mission-control-v
 ```
 
 Noch **nicht** gemacht — aendert Git-Konfiguration in den Repos des Users.
+
+---
+
+## Abschluss der Coding Lane (21.08.2026, abends)
+
+### Der Zugang: ein SSH-Schluessel, kein Token mehr
+
+**Der Ausloeser:** Mitten in der Sitzung scheiterte ein Push, der eine Stunde
+vorher noch ging — `remote: Failed to authenticate user`. Der Git Credential
+Manager haelt fuer Gitea ein **OAuth-Token mit einer Stunde Laufzeit**. Damit ist
+HTTP fuer einen Agenten, der selbst pushen soll, strukturell ungeeignet.
+
+**Was dabei herauskam:** Giteas SSH war **nie funktionsfaehig**. In der `app.ini`
+stand zwar `DISABLE_SSH = false` und `SSH_PORT = 22`, aber im Container gibt es
+**keinen `git`-Benutzer** und keine `authorized_keys` — Port 22 gehoert dem
+System-sshd. Es sah nur so aus, als koennte man ueber SSH klonen.
+
+**Loesung:** Giteas **eingebauten** SSH-Server eingeschaltet (Port 22 ist belegt,
+deshalb 2222). Der verwaltet die Schluessel selbst, direkt aus der Datenbank —
+kein `git`-Benutzer, keine `authorized_keys`.
+
+```ini
+# /etc/gitea/app.ini, [server]   (Sicherung: app.ini.bak-20260821)
+SSH_PORT = 2222
+SSH_LISTEN_PORT = 2222
+START_SSH_SERVER = true
+SSH_LISTEN_HOST = 0.0.0.0
+```
+
+‼️‼️ **Der SSH-Benutzer heisst `gitea`, NICHT `git`.** Gitea laeuft unter diesem
+Namen und weist alles andere ab. Die Fehlermeldung steht nur im Gitea-Log, nicht
+beim Client — ssh sagt bloss `Permission denied (publickey)`:
+
+```
+Invalid SSH username git - must use gitea for all git operations via ssh
+```
+
+**Auf dem PC** (`~/.ssh/config`) — noetig, weil hier **acht** Schluessel liegen
+und ssh sonst der Reihe nach durchprobiert, bis Gitea abbricht:
+
+```
+Host 192.168.178.153 gitea gitea.heimnetz
+    HostName 192.168.178.153
+    Port 2222
+    User gitea
+    IdentityFile ~/.ssh/id_general
+    IdentitiesOnly yes
+```
+
+Der Schluessel `id_general` ist in Gitea hinterlegt (Nr. 3) — **derselbe, mit dem
+du auf Box, pve und Arcane kommst.** Von acht Zugangsdaten auf einen.
+
+Alle sieben PC-Repos stehen jetzt auf
+`ssh://gitea@192.168.178.153:2222/Hitonabi/<repo>.git`.
+Das TTT2-Projekt bleibt unberuehrt — es haengt an einer anderen Domain und ist
+als „Finished" markiert.
+
+### Gemessen, nicht angenommen
+
+| Test | Ergebnis |
+|---|---|
+| `ssh -T gitea` | „Hi there, Hitonabi! You've successfully authenticated with the key named id_general" |
+| Push aus PowerShell | 8 Commits, `7c23ebf..25dbfb2` |
+| **Push aus dem Agenten** | durchgelaufen, **keine Passwortabfrage** |
+| Erzwungener Push aus dem Agenten | vom Werkzeug-Zaun abgewiesen |
+| `push-und-sync.ps1` komplett | Commit → Push → Box zieht nach |
+
+### Der Sonderfall MC2
+
+`projekte-sync` zieht `mission-control-v2` **absichtlich nicht** — die Box
+bedient daraus den laufenden Dienst auf `:9001`. Nach einem Push steht dort
+weiter der alte Commit, und das ist richtig so. Das Live-Deployment braucht
+seinen eigenen, bewussten Schritt. Alle anderen Projekte werden normal gezogen.
+
+### Fallen fuer das naechste Mal
+
+- **`sed` mit `$` und `\n` ueber PowerShell zerlegt sich.** Der erste Anlauf,
+  die `app.ini` zu aendern, lief ins Leere und die Datei blieb unveraendert —
+  ohne Fehlermeldung. In einzelne Ersetzungen zerlegen und **danach nachsehen**.
+- Ein Dienst-Neustart nach einer Konfig-Aenderung ist noch keine Bestaetigung:
+  Gitea startete brav neu — mit der alten Datei.
+- Acht SSH-Schluessel auf dem PC sind selbst ein Befund. `IdentitiesOnly yes`
+  ist Pflicht, sonst bricht die Gegenseite vorher ab.