$./ssh-forwarding

A tunnel. Not a personality.

SSH can carry other TCP through the session you already have. This page is how. Login is still ssh user@kire.net. In the examples, user is you and the ports are yours.

What this page is. Local (-L), remote (-R), and dynamic (-D / SOCKS) forwarding on a KIRE shell. Commands you can paste. Notes for people who already know the flags.

Who it is for. You have a KIRE Linux account. You want to reach a service on the shell from home, poke a local port out through the shell, or run a SOCKS client out of a network that hates you. If you wanted a commercial VPN product, you are on the wrong brochure. See ./vpn.

$why-a-kire-shell

A closet Pi dies when the roommate finds the power strip. A random VPS is “fine until it is not.” The tunnel lives on a box that already has ident, a PTR, and DDoS in front of the nick.

Always-on. Laptop lid is not a hosting plan. screen/tmux keep the SSH client attached; the shell keeps the other end. Process limits still apply — a forward is a process. Starter has one background slot. Standard is why most people are not on Starter.

$cheat-sheet

flag	what it does	when to use it
`-L`	local listen → dest through the shell	reach something on the shell (or beyond it) from your laptop
`-R`	listen on the shell → dest on your side	expose a local dev port via the shell’s address
`-D`	SOCKS proxy on your side, egress via the shell	browser / client through a hostile network
`-N`	no remote command	you only wanted the forward
`-f`	background after auth	or just use tmux and stay honest
`-n`	no stdin	scripts, autossh

$for-beginners

A tunnel is SSH carrying some other TCP so you do not have to open a hole in the house.

Replace user and the ports with yours.

Reach a service on the shell from home (`-L`)

Something is listening on the shell on 8888. You want it on your laptop as localhost:8080.

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

Then point the client at 127.0.0.1:8080. Traffic walks through SSH and hits 8888 on the shell. The service never has to face the internet.

Expose a local port through the shell (`-R`)

A thing on your laptop listens on 3000. You want it reachable as port 9000 on the shell — for you, a bot, a coworker who already has shell access, not the entire AS.

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

By default that listen is often 127.0.0.1:9000 on the shell. Only processes on the shell can connect. If you needed the vhost to accept it from outside, that is GatewayPorts / a public bind — expert track, and not a toy.

SOCKS (`-D`)

ssh -N -D 1080 user@kire.net

Browser: SOCKS5 host 127.0.0.1 port 1080. Proxy DNS through SOCKS or you leak lookups to the cafe. Firefox: Settings → Network → Manual → SOCKS5, check “Proxy DNS when using SOCKS v5.” Chromium is ruder; use a dedicated profile or a wrapper.

Keep it in tmux

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

screen works. Eggdrop does not belong in either. A forward does.

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

~/.ssh/config so you stop typing the novel:

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

Then ssh -N kire. ExitOnForwardFailure means a dead bind is a dead session, not a silent lie.

GatewayPorts is a sshd setting. If it is no (common), -R binds loopback on the shell even if you asked for a public address. clientspecified or yes is how -R [shell.kire.net:]9000:127.0.0.1:3000 becomes something the outside can hit. We do not promise that knob is on. If you need a public reverse forward, ask instead of assuming.

Bind addresses matter. -L 127.0.0.1:8080:127.0.0.1:8888 is not the same as -L 0.0.0.0:8080:.... Do not publish 22, 3389, or anything you would not put on a postcard to 0.0.0.0 because you felt clever. Privileged ports (< 1024) need root. You do not have root on a shell.

Multiple forwards on one session are fine. Jump hosts: -J / ProxyJump. You already knew that.

Keepalives: ServerAliveInterval on the client. NAT in the middle will otherwise eat idle tunnels. That is not an idle-timeout we invented for you.

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

-M 0 lets SSH’s own keepalives do the watching. A systemd --user unit is the same command with Restart=always. It still counts against process limits.

TCP-over-TCP hurts. SSH is TCP. Stuffing more TCP (bulk sync, nested tunnels, “VPN but SSH”) through it will stall in interesting ways. SOCKS for a browser is fine. A filesystem mirror is not. If you needed a real overlay network, read ./vpn and then probably still use -D.

A dumb TCP relay on the shell is a different tool. See ./proxies.

$dont

Open proxy. Public SOCKS. “Free VPN for the channel.” We will notice. AUP.
Forward services you do not own. Scanning, spam, mining: still no.
Bind admin protocols on all interfaces for the bit.
Turn a Starter account into a mesh of autossh daemons and then open a ticket about process limits.

$smaller-tool

Tunnel · TCP/SSL proxy · WireGuard. Pick the smallest one that solves the job. SOCKS is usually enough. A VPN is usually vanity.

client area order a shell ask a human