wiki: add SELinux AVC chart, enriched alerts, new server setup, and pending articles; update indexes

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

05-troubleshooting/networking/tailscale-ssh-reauth-prompt.md

@@ -0,0 +1,66 @@
+# Tailscale SSH: Unexpected Re-Authentication Prompt
+
+If a Tailscale SSH connection unexpectedly presents a browser authentication URL mid-session, the first instinct is to check the ACL policy. However, this is often a one-off Tailscale hiccup rather than a misconfiguration.
+
+## Symptoms
+
+- SSH connection to a fleet node displays a Tailscale auth URL:
+  ```
+  To authenticate, visit: https://login.tailscale.com/a/xxxxxxxx
+  ```
+- The prompt appears even though the node worked fine previously
+- Other nodes in the fleet connect without prompting
+
+## What Causes It
+
+Tailscale SSH supports two ACL `action` values:
+
+| Action | Behavior |
+|---|---|
+| `accept` | Trusts Tailscale identity — no additional auth required |
+| `check` | Requires periodic browser-based re-authentication |
+
+If `action: "check"` is set, every session (or after token expiry) will prompt for browser auth. However, even with `action: "accept"`, a one-off prompt can appear due to a Tailscale daemon glitch or key refresh event.
+
+## How to Diagnose
+
+### 1. Verify the ACL policy
+
+In the Tailscale admin console (or via `tailscale debug acl`), inspect the SSH rules. For a trusted homelab fleet, the rule should use `accept`:
+
+```json
+{
+    "src":    ["autogroup:member"],
+    "dst":    ["autogroup:self"],
+    "users":  ["autogroup:nonroot", "root"],
+    "action": "accept",
+}
+```
+
+If `action` is `check`, that is the root cause — change it to `accept` for trusted source/destination pairs.
+
+### 2. Confirm it was a one-off
+
+If the ACL already shows `accept`, the prompt was transient. Test with:
+
+```bash
+ssh <hostname> "echo ok"
+```
+
+No auth prompt + `ok` output = resolved. Note that this test is only meaningful if the previous session's auth token has expired, or you test from a different device that hasn't recently authenticated.
+
+## Fix
+
+**If ACL shows `check`:** Change to `accept` in the Tailscale admin console under Access Controls. Takes effect immediately — no server changes needed.
+
+**If ACL already shows `accept`:** No action required. The prompt was a one-off Tailscale event (daemon restart, key refresh, etc.). Monitor for recurrence.
+
+## Notes
+
+- ~~Port 2222 on **MajorRig** previously existed as a hard bypass for Tailscale SSH browser auth. This workaround was retired on 2026-03-25 after the Tailscale SSH authentication issue was resolved. The entire fleet now uses port 22 uniformly.~~
+- The `autogroup:self` destination means the rule applies when connecting from your own devices to your own devices — appropriate for a personal homelab fleet.
+
+## Related
+
+- [[Network Overview]] — Tailscale fleet inventory and SSH access model
+- [[SSH-Aliases]] — Fleet SSH access shortcuts

05-troubleshooting/networking/windows-sshd-stops-after-reboot.md

@@ -48,7 +48,7 @@ The Windows OpenSSH Server is installed as a Windows Feature (`Add-WindowsCapabi
 
 - **This is a Windows-side issue** — WSL2 itself is unaffected. The service must be started and configured from Windows, not from within WSL2.
 - **Elevated PowerShell required** — `Start-Service` and `Set-Service` for sshd will return "Access is denied" if run without Administrator privileges.
-- **Port 2222 is also affected** — both the standard port 22 and the bypass port 2222 on MajorRig are served by the same `sshd` service.
+- **Port 2222 was retired (2026-03-25)** — the bypass port 2222 on MajorRig is no longer in use. The entire fleet now uses port 22 uniformly after the Tailscale SSH auth fix. Only port 22 needs to be verified when troubleshooting sshd.
 - **Default shell still works once fixed** — MajorRig's sshd is configured to use `C:\Windows\System32\wsl.exe` as the default shell, dropping SSH sessions directly into WSL2/Bash. This config is preserved across service restarts.
 
 ---