$./ssh-forwarding

Ein Tunnel. Keine Persönlichkeit.

SSH kann anderes TCP durch die Session tragen, die du schon hast. Diese Seite sagt wie. Login bleibt ssh user@kire.net. In den Beispielen bist user du, und die Ports sind deine.

Was diese Seite ist. Lokales (-L), entferntes (-R) und dynamisches (-D / SOCKS) Forwarding auf einer KIRE-Shell. Befehle zum Einfügen. Notizen für Leute, die die Flags schon kennen.

Für wen. Du hast einen KIRE-Linux-Account. Du willst einen Dienst auf der Shell von zu Hause erreichen, einen lokalen Port durch die Shell nach außen strecken, oder einen SOCKS-Client aus einem Netz führen, das dich hasst. Wenn du ein kommerzielles VPN wolltest, bist du in der falschen Broschüre. Siehe ./vpn.

$why-a-kire-shell

Ein Pi im Schrank stirbt, wenn der Mitbewohner die Steckerleiste findet. Ein zufälliger VPS ist „okay, bis er es nicht mehr ist“. Der Tunnel lebt auf einer Kiste, die schon ident, einen PTR und DDoS vor dem Nick hat.

Immer an. Der Laptopdeckel ist kein Hosting. screen/tmux halten den SSH-Client dran; die Shell hält das andere Ende. Prozesslimits gelten weiter — ein Forward ist ein Prozess. Starter hat einen Hintergrund-Slot. Standard ist der Grund, warum die meisten nicht auf Starter sind.

$cheat-sheet

flag	was es tut	wann
`-L`	lokal lauschen → Ziel durch die Shell	etwas auf der Shell (oder dahinter) vom Laptop erreichen
`-R`	auf der Shell lauschen → Ziel bei dir	einen lokalen Dev-Port über die Adresse der Shell zeigen
`-D`	SOCKS-Proxy bei dir, Ausgang über die Shell	Browser / Client durch ein feindliches Netz
`-N`	kein Remote-Befehl	du wolltest nur den Forward
`-f`	Hintergrund nach Auth	oder einfach tmux und ehrlich bleiben
`-n`	kein stdin	Skripte, autossh

$for-beginners

Ein Tunnel ist SSH, das anderes TCP trägt, damit du kein Loch ins Haus bohren musst.

Ersetze user und die Ports durch deine.

Einen Dienst auf der Shell von zu Hause erreichen (`-L`)

Auf der Shell lauscht etwas auf 8888. Du willst es auf dem Laptop als localhost:8080.

ssh -N -L 8080:127.0.0.1:8888 user@kire.net

Dann zeig den Client auf 127.0.0.1:8080. Der Traffic läuft durch SSH und trifft 8888 auf der Shell. Der Dienst muss nie ins Internet schauen.

Einen lokalen Port durch die Shell zeigen (`-R`)

Etwas auf deinem Laptop lauscht auf 3000. Du willst es als Port 9000 auf der Shell erreichbar — für dich, einen Bot, einen Kollegen mit Shell-Zugang, nicht das ganze AS.

ssh -N -R 9000:127.0.0.1:3000 user@kire.net

Standardmäßig ist das Lauschen oft 127.0.0.1:9000 auf der Shell. Nur Prozesse auf der Shell können verbinden. Wenn der vhost es von außen annehmen soll, ist das GatewayPorts / ein öffentliches Bind — Expertenstrecke, kein Spielzeug.

SOCKS (`-D`)

ssh -N -D 1080 user@kire.net

Browser: SOCKS5-Host 127.0.0.1 Port 1080. DNS durch SOCKS, sonst leckst du Lookups ans Café. Firefox: Einstellungen → Netzwerk → Manuell → SOCKS5, „DNS über SOCKS v5 proxyen“ an. Chromium ist ruppiger; nimm ein eigenes Profil oder einen Wrapper.

In tmux lassen

tmux new -s fwd
ssh -N -D 1080 user@kire.net
# detach: Ctrl-b d
# later: tmux attach -t fwd

screen geht. Eggdrop gehört in keines von beiden. Ein Forward schon.

$for-people-who-already-know-the-flags

~/.ssh/config, damit du den Roman nicht mehr tippst:

Host kire
  HostName kire.net
  User user
  ServerAliveInterval 30
  ServerAliveCountMax 4
  ExitOnForwardFailure yes
  # LocalForward 8080 127.0.0.1:8888
  # RemoteForward 9000 127.0.0.1:3000
  # DynamicForward 1080

Dann ssh -N kire. ExitOnForwardFailure heißt: ein totes Bind ist eine tote Session, keine stille Lüge.

GatewayPorts ist eine sshd-Einstellung. Steht sie auf no (üblich), bindet -R Loopback auf der Shell, auch wenn du eine öffentliche Adresse wolltest. clientspecified oder yes macht aus -R [shell.kire.net:]9000:127.0.0.1:3000 etwas, das außen treffen kann. Wir versprechen nicht, dass der Schalter an ist. Brauchst du ein öffentliches Reverse-Forward, frag, statt zu raten.

Bind-Adressen zählen. -L 127.0.0.1:8080:127.0.0.1:8888 ist nicht -L 0.0.0.0:8080:.... Veröffentliche nicht 22, 3389 oder irgendwas, das du nicht auf eine Postkarte an 0.0.0.0 schreiben würdest, nur weil du dich clever fühltest. Privilegierte Ports (< 1024) brauchen root. Root hast du auf einer Shell nicht.

Mehrere Forwards auf einer Session sind in Ordnung. Jump-Hosts: -J / ProxyJump. Das wusstest du.

Keepalives: ServerAliveInterval am Client. Sonst frisst das NAT in der Mitte idle Tunnel. Das ist kein Idle-Timeout, das wir für dich erfunden haben.

autossh -M 0 -N -o "ServerAliveInterval 30" -o "ExitOnForwardFailure yes" -D 1080 user@kire.net

-M 0 lässt SSHs eigene Keepalives aufpassen. Eine systemd --user Unit ist derselbe Befehl mit Restart=always. Zählt trotzdem gegen die Prozesslimits.

TCP-über-TCP tut weh. SSH ist TCP. Noch mehr TCP (Bulk-Sync, verschachtelte Tunnel, „VPN aber SSH“) da durchzustopfen stockt auf interessante Arten. SOCKS für einen Browser ist fein. Ein Dateisystem-Spiegel nicht. Brauchtest du ein echtes Overlay-Netz, lies ./vpn und benutz dann wahrscheinlich trotzdem -D.

Ein dummes TCP-Relay auf der Shell ist ein anderes Werkzeug. Siehe ./proxies.

$dont

Open Proxy. Öffentliches SOCKS. „Gratis-VPN für den Channel.“ Wir merken das. AUP.
Dienste weiterleiten, die dir nicht gehören. Scannen, Spam, Mining: weiter nein.
Admin-Protokolle auf allen Interfaces binden, nur für den Move.
Aus einem Starter-Konto ein Netz aus autossh-Daemons machen und dann ein Ticket über Prozesslimits aufmachen.

$smaller-tool

Tunnel · TCP/SSL-Proxy · WireGuard. Nimm das kleinste, das die Aufgabe löst. SOCKS reicht meist. Ein VPN ist meist Eitelkeit.

Kundenbereich eine Shell bestellen einen Menschen fragen