$./ssh-forwarding
Un túnel. No una personalidad.
SSH puede llevar otro TCP por la sesión que ya tienes. Esta página es el cómo. El login sigue siendo ssh user@kire.net. En los ejemplos, user eres tú y los puertos son tuyos.
Qué es esta página. Reenvío local (-L), remoto (-R) y dinámico (-D / SOCKS) en un shell KIRE. Comandos para pegar. Notas para quien ya conoce los flags.
Para quién. Tienes una cuenta Linux KIRE. Quieres llegar a un servicio del shell desde casa, sacar un puerto local a través del shell, o sacar un cliente SOCKS de una red que te odia. Si querías un producto VPN comercial, estás en el folleto equivocado. Ver ./vpn.
$why-a-kire-shell
Un Pi de armario muere cuando el compañero de piso encuentra la regleta. Un VPS cualquiera está «bien hasta que deja de estarlo». El túnel vive en una caja que ya tiene ident, un PTR y DDoS delante del nick.
Siempre encendido. La tapa del portátil no es un plan de hosting. screen/tmux mantienen el cliente SSH pegado; el shell mantiene el otro extremo. Los límites de procesos siguen valiendo — un forward es un proceso. Starter tiene un solo slot de segundo plano. Standard es la razón de que la mayoría no esté en Starter.
$cheat-sheet
| flag | qué hace | cuándo usarlo |
|---|---|---|
-L | escucha local → destino a través del shell | llegar a algo en el shell (o más allá) desde tu portátil |
-R | escucha en el shell → destino de tu lado | exponer un puerto de dev local vía la dirección del shell |
-D | proxy SOCKS de tu lado, salida vía el shell | navegador / cliente a través de una red hostil |
-N | sin comando remoto | solo querías el forward |
-f | segundo plano tras la auth | o usa tmux y sé honesto |
-n | sin stdin | scripts, autossh |
$for-beginners
Un túnel es SSH llevando otro TCP para no abrir un agujero en la casa.
Sustituye user y los puertos por los tuyos.
Llegar a un servicio del shell desde casa (-L)
Algo escucha en el shell en el 8888. Lo quieres en tu portátil como localhost:8080.
ssh -N -L 8080:127.0.0.1:8888 user@kire.netLuego apunta el cliente a 127.0.0.1:8080. El tráfico cruza SSH y pega en el 8888 del shell. El servicio nunca tiene que mirar a internet.
Exponer un puerto local a través del shell (-R)
Una cosa en tu portátil escucha en el 3000. La quieres alcanzable como puerto 9000 en el shell — para ti, un bot, un colega que ya tiene acceso al shell, no todo el AS.
ssh -N -R 9000:127.0.0.1:3000 user@kire.netPor defecto esa escucha suele ser 127.0.0.1:9000 en el shell. Solo los procesos del shell pueden conectar. Si necesitabas que el vhost lo aceptara desde fuera, eso es GatewayPorts / un bind público — nivel experto, y no un juguete.
SOCKS (-D)
ssh -N -D 1080 user@kire.netNavegador: host SOCKS5 127.0.0.1 puerto 1080. Pasa el DNS por SOCKS o se te fugan los lookups al café. Firefox: Ajustes → Red → Manual → SOCKS5, marca «Proxy DNS al usar SOCKS v5». Chromium es más bruto; usa un perfil dedicado o un wrapper.
Déjalo en tmux
tmux new -s fwd
ssh -N -D 1080 user@kire.net
# detach: Ctrl-b d
# later: tmux attach -t fwdscreen vale. Eggdrop no va en ninguno de los dos. Un forward sí.
$for-people-who-already-know-the-flags
~/.ssh/config para dejar de teclear la novela:
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 1080Luego ssh -N kire. ExitOnForwardFailure significa que un bind muerto es una sesión muerta, no una mentira callada.
GatewayPorts es un ajuste de sshd. Si está en no (lo normal), -R hace bind al loopback del shell aunque pidieras una dirección pública. clientspecified o yes es como -R [shell.kire.net:]9000:127.0.0.1:3000 se vuelve algo que el exterior puede alcanzar. No prometemos que ese botón esté encendido. Si necesitas un reverse forward público, pregunta en vez de suponerlo.
Las direcciones de bind importan. -L 127.0.0.1:8080:127.0.0.1:8888 no es lo mismo que -L 0.0.0.0:8080:.... No publiques 22, 3389, ni nada que no pondrías en una postal a 0.0.0.0 por haberte creído listo. Los puertos privilegiados (< 1024) necesitan root. No tienes root en un shell.
Varios forwards en una sesión van bien. Jump hosts: -J / ProxyJump. Ya lo sabías.
Keepalives: ServerAliveInterval en el cliente. Si no, el NAT del medio se come los túneles idle. Eso no es un idle-timeout que inventamos para ti.
autossh -M 0 -N -o "ServerAliveInterval 30" -o "ExitOnForwardFailure yes" -D 1080 user@kire.net-M 0 deja que los keepalives del propio SSH vigilen. Una unidad systemd --user es el mismo comando con Restart=always. Sigue contando en los límites de procesos.
TCP sobre TCP duele. SSH es TCP. Meterle más TCP (sync masivo, túneles anidados, «VPN pero SSH») se atasca de formas interesantes. SOCKS para un navegador va bien. Un espejo de sistema de archivos, no. Si necesitabas una red overlay de verdad, lee ./vpn y luego probablemente sigas con -D.
Un relé TCP tonto en el shell es otra herramienta. Ver ./proxies.
$dont
- Open proxy. SOCKS público. «VPN gratis para el canal.» Nos enteramos. AUP.
- Reenviar servicios que no son tuyos. Scanning, spam, mining: sigue siendo no.
- Hacer bind de protocolos de admin en todas las interfaces por el gesto.
- Convertir una cuenta Starter en una malla de daemons autossh y luego abrir un ticket por los límites de procesos.
$smaller-tool
Túnel · proxy TCP/SSL · WireGuard. Elige la más pequeña que resuelva el trabajo. SOCKS suele bastar. Una VPN suele ser vanidad.