$./ssh-forwarding

Un tunnel. Pas une personnalité.

SSH peut porter un autre TCP dans la session que tu as déjà. Cette page dit comment. Le login reste ssh user@kire.net. Dans les exemples, user c’est toi et les ports sont les tiens.

Ce que cette page est. Transfert local (-L), distant (-R) et dynamique (-D / SOCKS) sur un shell KIRE. Des commandes à coller. Des notes pour ceux qui connaissent déjà les flags.

Pour qui. Tu as un compte Linux KIRE. Tu veux joindre un service du shell depuis chez toi, sortir un port local à travers le shell, ou faire sortir un client SOCKS d’un réseau qui te déteste. Si tu voulais un VPN commercial, tu es sur la mauvaise brochure. Voir ./vpn.

$why-a-kire-shell

Un Pi dans un placard meurt quand le coloc trouve la multiprise. Un VPS au hasard est « très bien jusqu’à ce qu’il ne le soit plus ». Le tunnel vit sur une machine qui a déjà ident, un PTR, et le DDoS devant le nick.

Toujours allumé. Le capot du portable n’est pas un hébergement. screen/tmux gardent le client SSH attaché ; le shell garde l’autre bout. Les limites de processus comptent encore — un forward est un processus. Starter a un seul slot d’arrière-plan. Standard existe parce que la plupart des gens ne sont pas sur Starter.

$cheat-sheet

flag	ce que ça fait	quand s’en servir
`-L`	écoute locale → destination à travers le shell	joindre quelque chose sur le shell (ou au-delà) depuis ton portable
`-R`	écoute sur le shell → destination de ton côté	exposer un port de dev local via l’adresse du shell
`-D`	proxy SOCKS de ton côté, sortie via le shell	navigateur / client à travers un réseau hostile
`-N`	pas de commande distante	tu ne voulais que le forward
`-f`	arrière-plan après l’auth	ou juste tmux, et reste honnête
`-n`	pas de stdin	scripts, autossh

$for-beginners

Un tunnel, c’est SSH qui porte un autre TCP pour ne pas ouvrir un trou dans la maison.

Remplace user et les ports par les tiens.

Joindre un service du shell depuis chez toi (`-L`)

Quelque chose écoute sur le shell en 8888. Tu le veux sur ton portable en localhost:8080.

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

Ensuite pointe le client sur 127.0.0.1:8080. Le trafic traverse SSH et tape 8888 sur le shell. Le service n’a jamais à voir Internet.

Exposer un port local à travers le shell (`-R`)

Un truc sur ton portable écoute en 3000. Tu le veux joignable en port 9000 sur le shell — pour toi, un bot, un collègue qui a déjà un accès shell, pas tout l’AS.

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

Par défaut cette écoute est souvent 127.0.0.1:9000 sur le shell. Seuls les processus du shell peuvent s’y connecter. Si tu voulais que le vhost l’accepte de dehors, c’est GatewayPorts / un bind public — piste expert, pas un jouet.

SOCKS (`-D`)

ssh -N -D 1080 user@kire.net

Navigateur : hôte SOCKS5 127.0.0.1 port 1080. Passe le DNS par SOCKS ou tu fuites les lookups au café. Firefox : Paramètres → Réseau → Manuel → SOCKS5, coche « Proxy DNS lorsque SOCKS v5 est utilisé ». Chromium est plus rude ; prends un profil dédié ou un wrapper.

Garde-le dans tmux

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

screen marche. Eggdrop n’a sa place dans aucun des deux. Un forward, si.

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

~/.ssh/config pour arrêter de taper le roman :

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

Puis ssh -N kire. ExitOnForwardFailure veut dire qu’un bind mort est une session morte, pas un mensonge silencieux.

GatewayPorts est un réglage sshd. S’il est à no (courant), -R bind le loopback du shell même si tu as demandé une adresse publique. clientspecified ou yes, c’est comme -R [shell.kire.net:]9000:127.0.0.1:3000 devient joignable de dehors. On ne promet pas que ce bouton est allumé. Si tu as besoin d’un reverse forward public, demande au lieu de supposer.

Les adresses de bind comptent. -L 127.0.0.1:8080:127.0.0.1:8888 n’est pas -L 0.0.0.0:8080:.... Ne publie pas 22, 3389, ni rien que tu ne mettrais pas sur une carte postale vers 0.0.0.0 parce que tu te sentais malin. Les ports privilégiés (< 1024) veulent root. Tu n’as pas root sur un shell.

Plusieurs forwards sur une session, c’est bon. Hôtes de saut : -J / ProxyJump. Tu le savais déjà.

Keepalives : ServerAliveInterval côté client. Sinon le NAT du milieu mange les tunnels inactifs. Ce n’est pas un idle-timeout qu’on a inventé pour toi.

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

-M 0 laisse les keepalives de SSH surveiller. Une unité systemd --user, c’est la même commande avec Restart=always. Ça compte quand même dans les limites de processus.

TCP-sur-TCP fait mal. SSH est du TCP. Y fourrer encore du TCP (sync massif, tunnels imbriqués, « VPN mais SSH ») va caler de façons intéressantes. SOCKS pour un navigateur, oui. Un miroir de système de fichiers, non. S’il te fallait un vrai réseau overlay, lis ./vpn et utilise probablement encore -D.

Un relais TCP bête sur le shell est un autre outil. Voir ./proxies.

$dont

Open proxy. SOCKS public. « VPN gratuit pour le salon. » On verra. AUP.
Forwarder des services qui ne sont pas à toi. Scan, spam, minage : toujours non.
Binder des protocoles d’admin sur toutes les interfaces pour le geste.
Transformer un compte Starter en maillage de démons autossh puis ouvrir un ticket sur les limites de processus.

$smaller-tool

Tunnel · proxy TCP/SSL · WireGuard. Prends le plus petit qui fait le travail. SOCKS suffit souvent. Un VPN, c’est souvent de la vanité.

espace client commander un shell demander à un humain