richlegrand/bitbang-cliEstablece acceso remoto seguro a una máquina con shell interactivo, transferencia de archivos y proxy web a través de WebRTC peer-to-peer cifrado de extremo a extremo, usando un navegador o CLI sin reenvío de puertos ni cuentas.
# BitBang CLI
[](https://github.com/richlegrand/bitbang-cli/actions/workflows/tests.yml)
`bitbang` es una herramienta multiusos de acceso remoto en un único binario estático. Desde cualquier navegador: acceso a un shell interactivo y a un explorador de archivos de la máquina remota. También puedes acceder a aplicaciones web en la red de esa máquina. Más allá del navegador, realiza reenvío de puertos TCP, copia de archivos y compartición de terminal. No requiere cuenta ni configuración: simplemente funciona.
En la máquina a la que quieres acceder:
```
curl -sSfL bitba.ng/install | sh
bitbang serve
```
`serve` imprime una URL. Ábrela en cualquier navegador y obtendrás un terminal, un explorador de archivos y un proxy hacia la red de esa máquina -- o accede a la misma máquina desde otro terminal con `bitbang connect <url>`, que añade reenvío de puertos (`-L`) y copia de archivos (`bitbang cp`). La conexión está cifrada de extremo a extremo y es peer-to-peer; el servidor `bitba.ng` presenta los dos extremos y luego se aparta.
`bitbang` es un único binario estático de Go. Forma parte del [proyecto BitBang](https://github.com/richlegrand/bitbang); este [whitepaper](https://github.com/richlegrand/bitbang/blob/main/whitepaper.md) cubre el diseño en profundidad.
## Cómo se compara
| | ngrok | Tailscale | `bitbang` |
| ------------------------------ | ---------------------- | ------------------------------ | ------------------- |
| Configuración antes del primer uso | Cuenta + authtoken | Cuenta + inicio de sesión en cada dispositivo | **Ejecutar un comando** |
| Para compartir algo, ejecutas | un servidor web, más ngrok | su cliente en ambas máquinas | **`bitbang serve`** |
| Lo que obtiene un navegador en el extremo remoto | el servidor web que ya estabas ejecutando | nada -- necesita su cliente | **un terminal, un explorador de archivos y aplicaciones web en la red remota** |
| Ruta de los datos | sus servidores | P2P (con respaldo por relay) | **P2P (con respaldo por relay)** |
| Cifrado de extremo a extremo | No por defecto | Sí | **Sí** |
## Recetas rápidas
**Acceder a un servicio en casa**
- [Monta tu NAS doméstico desde cualquier lugar (SMB)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#mount-your-home-nas-from-anywhere-smb)
- [Ve tu biblioteca multimedia desde cualquier lugar (Jellyfin)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#watch-your-media-library-from-anywhere-jellyfin)
- [Usa tu propio LLM desde cualquier lugar (Ollama, Open WebUI)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#use-your-own-llm-from-anywhere-ollama-open-webui)
- [Consulta tus cámaras de seguridad (Frigate)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#check-your-security-cameras-frigate)
- [Accede a tu domótica sin exponerla (Home Assistant)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#reach-your-home-automation-without-exposing-it-home-assistant)
- [Imprime en tu impresora doméstica (IPP, CUPS)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#print-to-your-home-printer-ipp-cups)
**Acceder a una máquina**
- [Obtén una shell en una máquina detrás de NAT](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#get-a-shell-on-a-machine-behind-nat)
- [Obtén una shell desde tu teléfono](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#get-a-shell-from-your-phone)
- [Escritorio remoto a una máquina Windows (RDP)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#remote-desktop-into-a-windows-machine-rdp)
- [Accede a un escritorio Linux o Mac (VNC)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#reach-a-linux-or-mac-desktop-vnc)
- [SSH a una máquina sin puerto abierto (OpenSSH)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#ssh-to-a-machine-with-no-open-port-openssh)
- [Configura una Raspberry Pi sin monitor](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#set-up-a-headless-raspberry-pi)
**Compartir con otra persona**
Compartir consiste simplemente en dar a alguien una URL única o un código QR que le dé acceso. Los permisos se pueden personalizar y configurar para que caduquen en minutos, horas, etc.
- [Compartir archivos sin subirlos a ningún sitio](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#share-files-without-uploading-them-anywhere)
- [Mostrar tu proyecto a alguien](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#show-someone-your-project)
- [Mostrar a alguien el error en el que estás atascado](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#show-someone-the-error-you-are-stuck-on)
- [Dar a alguien un acceso que caduca](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#give-someone-access-that-expires)
- [Consultar tu sesión de agente desde tu teléfono (Claude Code, tmux)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#check-your-agent-session-from-your-phone-claude-code-tmux)
- [Arreglar el router de otra persona](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#fix-someone-elses-router)
**Desarrollo y dispositivos**
- [Acceder a una base de datos desde tu máquina de desarrollo (Postgres, MySQL)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#reach-a-database-from-your-dev-machine-postgres-mysql)
- [Sincronizar dispositivos que no pueden encontrarse entre sí (Syncthing)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#sync-devices-that-cannot-find-each-other-syncthing)
- [Observar un robot desde un navegador (ROS, Foxglove)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#watch-a-robot-from-a-browser-ros-foxglove)
**Técnicas**
- [Qué expone un listener de reenvío](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#what-a-forwarding-listener-exposes)
- [Permitir que otras máquinas de tu LAN usen un reenvío](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#let-other-machines-on-your-lan-use-a-forward)
- [Se sabe que no funciona](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#known-not-to-work)
## Uso de `bitbang`
Toda conexión tiene dos extremos: un **listener** (`bitbang serve`, ejecutándose en la máquina a la que se accede) y un **connector** (un navegador, o la CLI `bitbang`, en la máquina que realiza el acceso). Una única URL de listener sirve a ambos tipos de connector.
### El listener: `bitbang serve`
```
bitbang serve # everything: shell + proxy + files + forward
bitbang serve shell # just a terminal
bitbang serve files ~/share # just a directory (-files-upload to allow uploads)
bitbang serve proxy localhost:8080 # just one web app, straight at the URL
bitbang serve proxy a.lan:80,b.lan:80 # ...or several, chosen in the browser
bitbang serve forward 127.0.0.1:22 # just TCP, for `connect -L`
bitbang serve shell files ~/share proxy nas.lan:8096 # any combination
```
Cada uno imprime un código QR, una URL y un código de emparejamiento. El modo determina qué puede hacer el listener en absoluto: `serve shell` no tiene forwarding que conceder, y un listener de solo forwarding nunca inicia un shell, así que no hay nada a lo que escalar.
Un valor predeterminado que conviene conocer: **el forwarding y el proxy alcanzan cualquier host:puerto que el listener pueda alcanzar**, no solo el que tenías en mente, así que un enlace entregado para una base de datos también alcanza el resto de esa red. Nombrar los objetivos después de la palabra lo restringe -- `forward db.internal:5432` alcanza eso y nada más.
### Compartir una sesión en ejecución: `bitbang share`
`serve shell` inicia un nuevo shell. `share` publica una sesión de tmux que ya está en ejecución:
```
bitbang share # publish the current tmux session
bitbang share --read-only # publish without a control URL
bitbang share status|stop|rotate
```
El comando regresa después de publicar, por lo que `Ctrl-Z`, `bitbang share`, `fg`
funciona para una tarea ya en curso. El alojamiento requiere tmux 3.2+ en Unix o
WSL. Los clientes nativos de Windows pueden abrir las URL pero no pueden alojar un share.
Por defecto, el comando imprime dos URL de portador:
- La **URL de control** puede escribir con la misma autoridad que el teclado local.
Solo un controlador puede conectarse a la vez.
- La **URL de visualización** es de solo lectura. La entrada se descarta antes de llegar a tmux, y
hasta `--max-viewers` espectadores pueden conectarse a la vez (por defecto 16).
`--read-only` omite por completo la credencial de control. Los límites de espectadores y controladores
se mantienen durante la vida útil de cada conexión, incluso antes de que abra un shell.
Los shares se ejecutan hasta que se detienen por defecto; `--ttl` establece una vida útil (p. ej., `--ttl 1h`).
Las URL de share son efímeras y nunca se guardan en `devices.json`. `share stop`,
la expiración del TTL o la eliminación de la sesión de origen desconectan a los pares remotos sin
detener la sesión de origen.
Volver a ejecutar `bitbang share` reimprime las URL del share en ejecución. Si pasas
una opción que no concuerda con lo que está en ejecución (digamos `--read-only`
contra un share que tiene una URL de control), lo indica en lugar de
devolver las URL antiguas; `bitbang share rotate` reemplaza el share
con uno que usa las nuevas opciones.
Un worker en segundo plano se ejecuta en una sesión de gestión de tmux `_bbshare_*` separada,
por lo que no hay daemon ni archivo PID que gestionar.
Compartir no cambia ninguna opción de tmux. Con el `window-size latest` predeterminado de tmux, la
ventana sigue al cliente de lectura-escritura activo; un espectador solitario sigue proporcionando el
único tamaño disponible. Si se ha sobrescrito `window-size`, `share` lo informa
pero no cambia la configuración del usuario.
### Distribuir acceso limitado: `bitbang link`
Un listener, una URL y tantos **enlaces de acceso** como necesites. Cada uno es un
código separado en esa misma URL, que otorga un subconjunto de lo que ofrece el listener
y, opcionalmente, caduca en un momento fijo:
```
bitbang link edit # add entries in $EDITOR
bitbang link ls # what you have handed out
bitbang link rm <label> # revoke one
bitbang link qr <label> # its URL and QR code
```
Una entrada es una línea de JSON en `~/.bitbang/bitbang/links.json`. Escribe una sin
código, recarga el listener en su consola, y este genera una:
```json
[
{"label": "ana", "grant": "files", "expires": "2026-09-01T00:00:00Z"},
{"label": "ben", "grant": "files /srv/photos"},
{"label": "dev", "grant": "shell forward 127.0.0.1:5432"}
]
```
```
0) owner files forward proxy shell
https://bitba.ng/8ach_I7oQk2vBb9xYzT0Lw#_vtQ0JCPe7s
1) ana files expires in 6d
https://bitba.ng/8ach_I7oQk2vBb9xYzT0Lw#T-Ty_HhvLfY
2) ben files /srv/photos
https://bitba.ng/8ach_I7oQk2vBb9xYzT0Lw#L6La8OzBO74
3) dev forward 127.0.0.1:5432 shell
https://bitba.ng/8ach_I7oQk2vBb9xYzT0Lw#8kmI3LYzB7E
```
`owner` es el código propio de la identidad y otorga todo lo que el listener sirve; envía
uno de los otros en su lugar. La consola acepta tanto la etiqueta como el número que aparece junto a
ella, así que `rm 2` y `rm ben` hacen lo mismo.
Un `grant` se escribe con las mismas palabras que acepta `serve`, y solo puede restringir lo que el
listener ya sirve. Eso significa que un enlace no se limita a elegir capacidades:
puede nombrar un subdirectorio de la carpeta compartida, un subconjunto de los objetivos de reenvío, o
un único comando para `shell`. Omite `grant` y el enlace otorga lo que sea que haga el listener. Pide algo fuera del alcance del listener y la consola lo rechaza con
el mismo mensaje que te daría `serve`.
La etiqueta es lo que identifica a un enlace, no sus términos, así que dos personas pueden tener enlaces
con grants y caducidad idénticos y aun así puedes revocar uno sin tocar
el otro.
La revocación y la caducidad alcanzan a las sesiones que ya están abiertas: la conexión se cierra
y se le dice al titular por qué, en lugar de quedarse en silencio. Y un código caducado se
retira en lugar de pausarse -- renovar una entrada acuña una nueva, así que la URL que
ya enviaste queda muerta.
### Emparejamiento con un código de 6 dígitos
Cuando no puedes pegar una URL ni escanear un código QR, como cuando estás en el teléfono, o a distancia de un grito, `bitbang serve` también imprime un breve **código de emparejamiento**. La otra parte abre `bitba.ng/<code>` (o ejecuta `bitbang connect <code>`), su pantalla muestra un segundo número de 6 dígitos, y te lee *ese* de vuelta. Tú lo escribes para aprobar. Un atacante de tipo machine-in-the-middle no puede hacer que los dos números coincidan, y el emparejamiento guarda las credenciales de conexión del dispositivo para la próxima vez, p. ej. `bitbang connect nas1`. Si conoces [Magic Wormhole](https://github.com/magic-wormhole/magic-wormhole), la forma es similar -- un código hablado que presenta de forma segura dos máquinas.
### Trae tu propio TURN
La mayoría de las conexiones van directamente de igual a igual. Cuando ambos extremos están detrás de un NAT que
no permite hole-punching, el tráfico necesita un relay, y por defecto ese es el nuestro. `-ice-servers`
apunta el listener a uno propio en su lugar:
```
bitbang serve -ice-servers ~/turn.json
```
El listener entrega la configuración al servidor de señalización en el registro, y el servidor
se la entrega a quien se conecte, de modo que ambos extremos usan tu relay y el nuestro nunca interviene.
Sirve cualquier coturn, o un proveedor alojado como Cloudflare o Twilio.
El archivo es JSON, en cualquiera de estas tres formas que te haya entregado tu proveedor:
```json
[{"urls": ["turn:turn.example.net:3478"], "username": "user", "credential": "pass"}]
```
```json
{"ice_servers": [{"urls": "stun:stun.example.net:3478"}]}
```
```json
{"iceServers": [{"urls": ["turn:turn.example.net:3478"], "username": "u", "credential": "p"}]}
```
`urls` acepta una cadena o una lista; `username` y `credential` son para TURN y pueden
omitirse en una entrada solo STUN. La ruta puede ser absoluta, relativa o con raíz `~`. Un archivo
que no se parsea detiene el listener al arrancar en lugar de recurrir silenciosamente a otra cosa.
Si una sesión termina siendo retransmitida sin que se haya solicitado, `bitbang connect` lo indica
en lugar de dejarte preguntándote por qué va lento. El listener lo registra
en cualquier caso (`via RELAY`), y `-relay` / `-norelay` fuerzan la cuestión en un sentido
u otro cuando estás diagnosticando una ruta.
Vale la pena decirlo: esto trata sobre quién transporta los bytes, no quién puede leerlos. Un relay solo
ve texto cifrado DTLS, incluido el nuestro. Ejecuta el tuyo propio cuando necesites más TURN del que podemos proporcionar (actualmente limitamos el tiempo).
### Conexión desde un navegador
Abre la URL. Según lo que se sirva, obtienes:
- **Shell** -- un terminal completo en la página (colores, redimensionamiento, copiar/pegar).
- **Files** -- navegar, previsualizar, descargar y subir.
- **Proxy** -- escribe una dirección de LAN (`nas.local`, `192.168.1.10:8080`, `localhost:3000/admin`) y usa la aplicación como si estuvieras en local. Los inicios de sesión, las cookies, las subidas y el streaming funcionan.
<!-- TODO: per-feature demos -->
<!-- Remote shell in a browser tab -->
<!-- Streaming Jellyfin through the proxy -->
### Conexión desde la CLI
```
bitbang connect <url> # interactive shell
bitbang connect <url> -- tail -f /var/log/syslog # one-shot command
bitbang connect <url> -L 15432:db.internal:5432 # local TCP forwarding
bitbang connect <url> -L 14450:nas.local:445 -L 15900:[fd00::20]:5900
bitbang cp <url>:/var/log/app.log ./app.log # copy files, scp-style
bitbang cp - <url>:/tmp/firmware.bin < firmware.bin # stdin/stdout work too
```
`-L` reenvía **solo TCP**, como `ssh -L`. `-L` se enlaza a `127.0.0.1` a menos que pases
`-g`, lo que hace que el puerto reenviado sea accesible desde tu red local -- y
cualquiera que llegue a él obtiene lo que sea que alcance el túnel, sin una
credencial de BitBang por delante.
El listener necesita `bitbang serve forward` o `bitbang serve`. Por defecto, un
enlace `forward` alcanza **cualquier host:puerto que el listener pueda alcanzar**, no solo
el que tenías en mente, así que un enlace entregado para una base de datos también alcanza el resto
de esa red. Restríngelo nombrando lo que puede alcanzar:
```
bitbang serve forward db.internal:5432 # this link reaches one service
```
Cada conexión o emparejamiento exitoso se guarda en `~/.bitbang/devices.json`, así que a partir de entonces basta con un nombre corto: `bitbang connect nas1`.
## Compatibilidad de plataformas
Un binario por plataforma, sin dependencias de tiempo de ejecución. Todo funciona
en todas partes excepto en las dos filas señaladas a continuación.
| | Linux | macOS | Windows |
| ---------------------------------------- | :---: | :---: | :-----: |
| Shell, archivos, proxy (`bitbang serve`) | sí | sí | sí |
| Reenvío TCP (`-L`) | sí | sí | sí |
| Enlaces de acceso -- concesión, caducidad, revocación | sí | sí | sí |
| Trae tu propio TURN | sí | sí | sí |
| Emparejamiento con un código de 6 dígitos | sí | sí | sí |
| La consola del listener (Enter) | sí | sí | sí |
| `bitbang connect`, `bitbang cp` | sí | sí | sí |
| Ver una sesión compartida | sí | sí | sí |
| **Alojar un recurso compartido** (`bitbang share`) | sí | sí | no * |
| **Redimensionar la terminal mientras está conectado** | sí | sí | no ** |
\* `bitbang share` publica una sesión de tmux, así que alojar una requiere tmux --
Linux, macOS o WSL. Windows nativo aún puede abrir URLs compartidas con
`bitbang connect`.
\*\* Un conector de Windows no detecta que su terminal se ha redimensionado, así que el
shell remoto conserva el tamaño con el que se inició hasta que te reconectas. Unix
obtiene esto de `SIGWINCH`, del cual Windows no tiene equivalente.
## Seguridad
- **Identidad autocertificada.** En la primera ejecución, `bitbang` genera un par de claves RSA en `~/.bitbang/<program>/`; el UID del dispositivo se deriva de la clave pública, así que suplantar un dispositivo significa encontrar una segunda preimagen de su UID.
- **El secreto nunca toca el servidor.** El código de acceso vive en el fragmento de la URL (`#…`), que los navegadores nunca envían -- `bitba.ng` intermedia la conexión sin ver jamás la credencial que la autoriza.
- **Cifrado de extremo a extremo.** Todo el tráfico viaja sobre DTLS de WebRTC. El servidor de señalización solo ve la clave pública, el UID derivado y los metadatos de conexión -- nunca tus datos. Un relay TURN, si se necesita, solo ve texto cifrado.
- **Emparejamiento verificado.** El número leído en voz alta en el emparejamiento por código es una cadena de autenticación corta (SAS), calculada de forma independiente en ambos extremos a partir de las huellas DTLS negociadas y dos nonces comprometidos -- un atacante en el medio, cuyas huellas necesariamente difieren, no puede hacer que los dos números coincidan.
- **La URL es una credencial de portador.** Cualquiera que la tenga obtiene lo que hayas elegido servir -- un shell, si ejecutaste `serve shell`. Compártela en consecuencia.
- **PIN opcional** (`--pin`) para configuraciones permanentes o sin interfaz, y **modo desechable** (`-ephemeral`) para una identidad nueva en cada ejecución.
- **Lo que el servidor sigue viendo.** No es nada. Intermedia la presentación, así que
observa las direcciones IP de ambos extremos, cuándo se conectan y cuánto
intercambian. El cifrado de extremo a extremo lo mantiene fuera de tus datos, no de los
metadatos que los rodean -- *confianza mínima* es una descripción más justa que
*sin confianza*.
- **Un navegador confía en la página que cargó.** El cliente de navegador es JavaScript
servido por el servidor de señalización, así que abrir una URL significa confiar en que ese servidor
sirva código honesto. `bitbang connect` no tiene tal dependencia: es un
binario que instalaste y verificaste con checksum. Si esa distinción te importa,
conéctate con la CLI.
Cómo se autentican mutuamente ambos extremos, de modo que el servidor de señalización no pueda
insertarse en la conexión, se detalla aquí: [*Trustless Signaling: Authentication Without a Central Authority*](https://github.com/richlegrand/bitbang/blob/main/trustless-signaling.md).
## ¿Por qué?
- **Nada que abrir ni configurar.** Funciona desde detrás de NAT, CGNAT o una red bloqueada -- sin cambios en el router, sin VPN, sin demonio de túnel.
- **Nada que instalar en el lado que se conecta.** Basta con un navegador. Hay una CLI disponible cuando quieres scripting, tuberías y copia de archivos.
- **Privado por diseño.** El tráfico es WebRTC/DTLS, de igual a igual. El servidor de señalización nunca lo ve; si no es posible una ruta directa, un relay TURN transporta únicamente texto cifrado.
- **Sin cuenta, sin telemetría.**
### ¿Por qué no usar simplemente SSH? ¿O Tailscale?
Respuesta corta: para una máquina a la que ya puedes acceder por SSH, o para un conjunto de tus propios
dispositivos en los que puedes instalar, sigue usando lo que ya tienes. `bitbang` es para cuando el
extremo remoto es una persona en lugar de un dispositivo, o cuando no puedes instalar nada
donde estás sentado. Ambas preguntas se responden en detalle en las
**[FAQ](https://github.com/richlegrand/bitbang-cli/blob/main/FAQ.md)**.
## Instalación
```
curl -sSfL bitba.ng/install | sh
```
Linux y macOS. Detecta tu SO y arquitectura (`amd64`, `arm64` y `armv7` en Linux), descarga el binario desde la última [versión de GitHub](https://github.com/richlegrand/bitbang-cli/releases), verifica su SHA-256 contra el `checksums.txt` de la versión y lo instala en `~/.local/bin/bitbang`.
Las compilaciones para Windows se publican como `bitbang-windows-amd64.exe` y
`bitbang-windows-arm64.exe`. Descarga el binario correspondiente desde Releases,
renómbralo a `bitbang.exe` y colócalo en tu `PATH`.
**Compilar desde el código fuente:** consulta [más abajo](#building-from-source).
**macOS y Gatekeeper.** El instalador de una línea anterior no se ve afectado: `curl` no
establece el atributo `com.apple.quarantine`, por lo que el binario que descarga se ejecuta
con normalidad. Si en cambio descargas `bitbang-darwin-arm64` desde la página de Releases
en un navegador, macOS lo pone en cuarentena y se niega a abrirlo, porque los binarios
de la versión no están notarizados. Elimínala con cualquiera de estas opciones:
```
xattr -d com.apple.quarantine ./bitbang-darwin-arm64
```
o haz clic derecho en el archivo en Finder y elige Abrir, lo que ofrece una
anulación única. Alternativamente, compila desde el código fuente, que nunca
aplica cuarentena.
**Windows y SmartScreen.** Lo mismo ocurre en Windows, por la misma
razón. Una descarga del navegador adjunta la Marca de la Web, por lo que la primera ejecución muestra
*"Windows protegió tu PC"* -- elige **Más información**, luego **Ejecutar de todos modos**. Los
binarios de la versión no están firmados digitalmente, así que esto es esperado en lugar de ser señal
de que algo esté mal. Obtener el `.exe` con `curl` o con `Invoke-WebRequest` de PowerShell
no la adjunta, y tampoco lo hace compilar desde el código fuente.
### Opciones de instalación
Fija una versión, cambia la ubicación o lee el script antes de ejecutarlo:
```
curl -sSfL bitba.ng/install | sh -s -- --version 0.5.0
curl -sSfL bitba.ng/install | sh -s -- --prefix /usr/local/bin
curl -sSfL bitba.ng/install -o install.sh && less install.sh && sh install.sh
```
Las etiquetas de versión no llevan el prefijo `v` (`0.5.0`, no `v0.5.0`).
### Cómo funciona la URL de instalación
`bitba.ng/install` es una redirección, no un script alojado. La cadena:
1. `curl` accede a `https://bitba.ng/install`, que responde con un 302 hacia [`install.sh`](https://github.com/richlegrand/bitbang-cli/blob/main/install.sh) en este repositorio (en `main`).
2. El script se ejecuta en tu shell, detecta el SO y la arquitectura, y descarga el binario desde `https://github.com/richlegrand/bitbang-cli/releases/latest/download/bitbang-linux-<arch>`.
3. Obtiene `checksums.txt` de la misma versión y verifica el SHA-256 del binario.
4. Se instala en `~/.local/bin` (se puede sobrescribir).
El script de instalación reside en este repositorio, junto al código que instala, de modo que puedes revisarlo junto con el binario, y el host canónico bitba.ng solo posee la URL corta. Quienes alojen su propia instancia pueden apuntar el `/install` de su propio host al script que distribuyan: la variable de entorno `INSTALL_URL` del servidor de señalización controla el destino de la redirección (vacía → 404).
## Referencia de comandos
Cada subcomando y flag está documentado en **[CLI.md](https://github.com/richlegrand/bitbang-cli/blob/main/CLI.md)**, y `bitbang <command>
--help` muestra lo mismo en la terminal.
## Compilar desde el código fuente
Requiere Go 1.25+. Go puro, enlazado estáticamente (`CGO_ENABLED=0`): compilación cruzada trivial, sin dependencias en tiempo de ejecución.
```
go build ./cmd/bitbang/
# cross-compile:
GOOS=linux GOARCH=arm64 go build -o bitbang-arm64 ./cmd/bitbang/
GOOS=linux GOARCH=arm GOARM=7 go build -o bitbang-armv7 ./cmd/bitbang/
GOOS=windows GOARCH=amd64 go build -o bitbang.exe ./cmd/bitbang/
GOOS=darwin GOARCH=arm64 go build -o bitbang-macos ./cmd/bitbang/
```
Desde el símbolo del sistema de Windows:
```bat
go build -o bitbang.exe .\cmd\bitbang
go test .\...
run_tests.cmd unit
```
Los comandos de shell, el uso compartido de archivos, el proxy y el cliente CLI son compatibles con
Windows. Los shells interactivos de navegador y CLI usan Windows ConPTY, incluidos
el eco de entrada del terminal, la edición de líneas, la salida VT y los eventos de redimensionamiento. ConPTY requiere
Windows 10 versión 1809 o Windows Server 2019 o posterior.
## Diagramas
<p align="center">
<img src="https://assets.kitploit.com/production/public/readmes/47068/d68fcddad62ab84f11a549906a2b5abf2330fb25f39b3c1a1266eac7257a080d.png" alt="shell de CLI de bitbang y uso compartido de archivos" width="760">
<img src="https://assets.kitploit.com/production/public/readmes/47068/55bb6866c22504a6434e3dee8cb998e747cd73cb9d0bfa5e0bc0ede7b90ce262.png" alt="operación del proxy de CLI de bitbang" width="720">
</p>
## Hoja de ruta
Disponible hoy: **shell, archivos y proxy**, accesibles desde el navegador o la CLI, además de **redirección de puertos TCP**, copia de archivos estilo scp, **emparejamiento ad-hoc** con una tabla de dispositivos guardada, **uso compartido de terminal** (`bitbang share`) y **enlaces de acceso** (`bitbang link`) que restringen y hacen caducar lo que concede una URL. Diseñado y en camino:
- **Puente serie** -- controlar un `/dev/ttyUSB0` remoto desde un puerto virtual local (p. ej., ejecutar Arduino IDE a través de internet). Se ha abierto un issue [aquí](https://github.com/richlegrand/bitbang-cli/issues/3).
- **Escritorio remoto** -- pantalla a través de una pista de vídeo WebRTC, teclado/ratón a través del canal de datos.
## Licencia
MIT -- véase [LICENSE](https://github.com/richlegrand/bitbang-cli/blob/main/LICENSE).
## Contribuciones
Issues y PRs bienvenidos.
Las recetas son distintas: viven en el [cookbook](https://github.com/richlegrand/bitbang/blob/main/cookbook.md),
en el repositorio [bitbang](https://github.com/richlegrand/bitbang), porque abarcan
todos los proyectos en lugar de este. Añadir una receta es un PR allí.
Lograr que se *liste* es un segundo PR pequeño por proyecto cuyo README debería mostrarla
-- la lista de [Recetas](#recipes) de arriba se mantiene aquí a mano. Eso es
deliberado: cada proyecto decide qué recetas merece la pena poner delante de sus
propios lectores, en lugar de que cada README vaya acumulando todas las recetas.