Recibir archivos desde la línea de comandos

Última actualización: 2026-09-01

Enviar es solo la mitad de la historia — tarde o temprano estás en el extremo receptor: un colega quiere entregarte un archivo por internet, una de tus propias máquinas quiere pasárselo a otra, o quieres ir a buscar algo en un servidor que administras. La CLI de Relayium cubre los tres casos con un comando distinto para cada uno, y ninguno necesita cuenta.

Elige receive cuando alguien te envía por código de emparejamiento, serve cuando quieres un buzón permanente al que máquinas de confianza puedan enviar en cualquier momento, y pull cuando eres tú quien va a buscar en un servidor al que ya puedes conectarte por ssh.

Tres formas de recibir, y cuándo aplica cada una

Qué comando ejecutas depende de quién inicia la transferencia y de cómo se conocen las dos máquinas:

• relayium receive <code> [destdir] — alguien te envía entre redes usando un código de emparejamiento que generó su CLI y te comunicó fuera de banda. Directo de igual a igual, con un código SAS que puedes comparar.
• relayium serve [--dir D] [--port N] [--once] [--allow-delete] — esta máquina escucha envíos en daemon directo por relayium://, en el puerto 9031 por defecto.
• relayium pull [user@]host:src <dest> — vas a buscar por SSH a un servidor al que ya puedes conectarte y recuperas archivos.

receive: alguien te envía un archivo entre redes

Esta es la mitad receptora de relayium send. La otra persona ejecuta relayium send <path> en su extremo (tras relayium login); su CLI genera un código de 6 dígitos, válido 5 minutos, y lo imprime. Te dice cuál es por cualquier canal en el que ambos confíen — una llamada, un mensaje de chat. Tú ejecutas receive con ese código:

relayium receive 483920

# o dentro de un directorio concreto
relayium receive 483920 ./downloads

1. Acuerda con el emisor cuándo va a ejecutar send. El código empieza a caducar en cuanto se acuña, no cuando te llega.

2. Recibe los seis dígitos por un canal en el que ambos confiéis: una llamada, una ventana de chat, la habitación en la que estáis.

3. Ejecuta receive desde el directorio donde deban caer los archivos, o nombra uno explícitamente.

   relayium receive 483920

   relayium receive 483920 ./downloads

4. Cuando ambos terminales impriman un código de verificación, lee el tuyo en voz alta y comprueba que coincide con el suyo. No es el código de emparejamiento, y es lo único que descarta un extremo suplantado.

5. No toques el terminal hasta que vuelva al prompt. Es una sola sesión en vivo: cerrar cualquiera de los dos extremos detiene la transferencia.

$ relayium receive 483920
verification code (SAS): 271044 — not the pairing code; compare it on both ends to rule out a substituted endpoint
path: direct

• La conexión es directa, de igual a igual y cifrada de extremo a extremo; ambos terminales imprimen el mismo SAS (cadena de autenticación corta) una vez conectados. Compáralo fuera de banda con el remitente para confirmar que las huellas de los certificados TLS fijados no fueron sustituidas y que el servicio de encuentro no suplantó a ninguno de los extremos. El SAS autentica los extremos; no demuestra cada salto de la ruta de red.
• Sin destino indicado: los archivos caen en el directorio actual.
• La misma regla de solo directo que send: si no puede hallarse ninguna ruta directa entre las dos redes, la transferencia falla en lugar de enrutarse por un retransmisor.
• Este es el propio protocolo de código de emparejamiento de la CLI — un código de la CLI solo se empareja con otra CLI. Hoy no interopera con el código de emparejamiento del navegador ni con el flujo de QR en relayium.com; eso es una posible adición futura, no algo en lo que puedas confiar todavía. Si solo tienes navegador, pídele al remitente un enlace de descarga de relayium up.
• El receptor nunca necesita una cuenta, en ninguna red. Solo el remitente inicia sesión, para que su CLI pueda generar el código.

serve: convierte esta máquina en un buzón a la escucha

serve funciona al revés: en lugar de que seas tú quien va a buscar, otras máquinas te envían directamente por relayium:// — pensado para máquinas en las que ya confías, como tu propio portátil enviando a un NAS, o un servidor de compilación dejando artefactos en una máquina que es tuya — por una conexión TLS 1.3 con anclaje, sin SSH, sin punto de encuentro.

relayium serve

# un directorio y un puerto concretos, permitiendo peticiones de borrado
relayium serve --dir ~/incoming --port 9031 --allow-delete

1. Arranca el receptor nombrando el directorio donde deben caer los envíos.

   relayium serve --dir ~/incoming

2. Cuando una máquina nueva empuja por primera vez, serve muestra su dirección y su huella y te pregunta. Apruébala una vez y los envíos posteriores de esa huella pasan en silencio.

3. Si este receptor va a funcionar sin terminal, no cuentes con esa pregunta: no hay nadie para responderla y un emisor desconocido se rechaza sin más. Usa la autorización previa de la sección siguiente.

• La primera vez que una máquina nueva te envía algo, serve (ejecutándose en un terminal) muestra su dirección y su huella y te pide que la apruebes una vez; después, los envíos de la misma huella pasan en silencio.
• Sin terminal — un servicio systemd, un script sin TTY — no hay a quién preguntar, así que un emisor no reconocido se rechaza de plano. En su lugar, autorízalo por adelantado usando la huella que el emisor imprime con relayium id:

Autorizar por adelantado para un serve desatendido

Para un serve que corre desatendido (systemd, un script en segundo plano), haz que el emisor ejecute relayium id para imprimir su huella, y luego apruébala de antemano desde el lado receptor:

relayium authorize <fingerprint>

• --dir fija dónde caen los archivos (por defecto el directorio actual); --once acepta una única transferencia y sale; --allow-delete deja que una petición --delete (espejo) entrante realmente elimine archivos aquí, y está desactivado por defecto.
• --config-dir (por defecto ~/.config/relayium) es donde viven la identidad de este host y su lista de huellas autorizadas — anúlalo si ejecutas serve como un servicio dedicado.

pull: ve a buscar y recupera de un servidor al que puedes conectarte por ssh

pull es el espejo de push: en lugar de esperar a que alguien te envíe algo, vas a buscar por tu acceso SSH existente y recuperas archivos.

relayium pull user@host:/path/to/files ./local-dest

1. Comprueba que la máquina remota tiene realmente la CLI. pull ejecuta relayium en el otro extremo y, a diferencia de push, no hay repliegue a tar: si falta el binario, falla la orden entera.

   ssh user@host command -v relayium

2. Si falta, instálala allí primero.

   curl -fsSL https://relayium.com/install.sh | sh

3. Trae los archivos por tu acceso SSH existente. -i y -p se comportan como los de ssh.

   relayium pull user@host:/path/to/files ./local-dest

• A diferencia de push, pull siempre necesita relayium ya instalado en el remoto — no hay respaldo con tar para hacer pull desde un servidor pelado. Si el remoto aún no lo tiene, instálalo allí primero con curl -fsSL https://relayium.com/install.sh | sh.
• Cada archivo se verifica con una comprobación SHA-256 por archivo. pull no reanuda: rechaza un destino que ya existe, por adelantado y antes de traer nada. Un pull interrumpido se termina trayendo las rutas que faltan, o con relayium sync en el mismo sentido. --no-resume se acepta aquí y no hace nada.
• -i y -p se comportan como los propios -i/-p de ssh, para un archivo de identidad o un puerto específico.

Cuando no funciona

Cinco fallos cubren casi todas las recepciones fallidas. Qué orden estabas ejecutando decide cuál aplica, y cada uno se zanja con una línea que leer o una orden que ejecutar.

Preguntas frecuentes

¿Necesito una cuenta para recibir archivos?

No. Las tres formas — receive, serve y pull — son completamente gratis y no necesitan una cuenta de Relayium por tu parte. El único inicio de sesión en todo esto es el del remitente en modo receive, para que su CLI pueda generar el código de emparejamiento.

¿relayium receive interopera con el código de emparejamiento del navegador?

No. El protocolo de código de emparejamiento de la CLI está separado del flujo de enlace de unión y QR del navegador en relayium.com — usan handshakes distintos y hoy no se hablan entre sí, así que un código de la CLI solo se empareja con otra CLI. Eso está en la hoja de ruta, no es algo en lo que puedas confiar todavía. Hasta entonces, quien reciba desde un navegador quiere un enlace de relayium up, no un código.

¿Qué pasa si una máquina desconocida envía a mi proceso serve a la escucha?

En un terminal, se te pide aprobarla por dirección y huella en su primer envío, y la aprobación se recuerda. Sin terminal — un servicio systemd, una tarea cron — no hay a quién preguntar, así que un emisor no reconocido se rechaza; autorízalo primero con relayium authorize <fingerprint>.

¿Puedo hacer pull desde un servidor que no tiene relayium instalado?

No. pull siempre necesita relayium en el extremo remoto; no hay respaldo con tar como lo hay para push. Instala relayium allí primero.

¿Dónde guarda relayium mi identidad y los pares de confianza?

En ~/.config/relayium por defecto — anula la ubicación con --config-dir en cualquier comando que toque la identidad o la confianza.

Sigue leyendo

• Enviar un archivo a alguien entre redes con la CLI de Relayium
• Ejecuta Relayium como un servicio de recepción siempre activo
• Transfiere archivos y texto desde la terminal con la CLI de Relayium
• Relayium vs croc: transferencia de archivos cifrada desde la terminal
• Relayium