2026 SSH-TCP-Forwarding fuer Teams auf Cloud-Mac: AllowTcpForwarding, PermitOpen & Audit-Checkliste

SSH-Port-Forwarding ist bequem, kann aber ohne Governance zur unkontrollierten Ausleitung werden. Teams auf Apple-Silicon-Cloud-Macs fuer iOS-Builds oder OpenClaw nutzen haeufig LocalForward; ohne dokumentierte Regeln kann ein kompromittierter Laptop ueber den gemieteten Host pivotieren.

Ergänzend: Bastion vs. direktes SSH, OpenClaw-Gateway-Tunnel, SSH-Key-Rotation. Standard: sshd restriktiv, Freigaben dokumentieren, Aenderungen per Ticket.

Wer braucht die Richtlinie

• Plattformteams, die einen MacLogin-Knoten mit Dienstleistern teilen.
• Security & Compliance, die Datenabfluesse erklaeren muessen.
• Automatisierung mit LocalForward fuer OpenClaw oder CI.

Entscheidungsmatrix

Muster	Risiko	Empfehlung
Keine dokumentierten Tunnel	Schatten-Pivots	AllowTcpForwarding no no bis Ticket
OpenClaw / Dev-Gateway	Zu breite Localhost-Freigabe	AllowTcpForwarding local + 127.0.0.1 — Bindung nur 127.0.0.1
DB- oder API-Debug	Laterale Bewegung	PermitOpen PermitOpen + Zeitfenster

Wichtige sshd-Parameter

• AllowTcpForwarding — wenn moeglich local statt yes.
• PermitOpen — Ziele fuer Remote-Forwards begrenzen.
• Match — strengere Defaults fuer Automationskonten.

Fuenf Rollout-Schritte

1. Bestand: ~/.ssh/config auf LocalForward pruefen.
2. Baseline: sshd -T versioniert ablegen.
3. Pilot: restriktives Match auf Staging-Knoten.
4. Kommunikation: Port-Matrix mit erstem SSH-Vertrauen veroeffentlichen.
5. Test: verweigerten Forward versuchen und Logs pruefen.

Audit & Incident

Monatlich log show stichprobenartig mit Tickets abgleichen. Vor Key-Rotation Beweise sichern — Key-Leitfaden.

FAQ

Kurzantworten passend zum FAQ-Schema.

AllowTcpForwarding ueberall aus? Nicht immer. Reine Build-Hosts ohne Tunnel ja; OpenClaw-Teams brauchen beschraenktes Forwarding.

Ersetzt PermitOpen eine Firewall? Nein. Nur sshd-Ziele; Segmentierung bleibt.

Wer genehmigt Ausnahmen? Security oder Platform per Ticket mit Ablaufdatum und CMDB.