Transferencias de servidor a servidor con la CLI de Relayium (daemon directo)

Última actualización: 2026-07-12

Cuando ambas máquinas son tuyas y cada una conoce la dirección de la otra, SSH es una fricción de más y un encuentro es pura sobrecarga. daemon directo está hecho exactamente para esto: un servidor escucha, el otro le hace push directamente sobre una conexión TLS 1.3 con anclaje. Sin retransmisor, sin SSH, sin código de emparejamiento: la confianza se basa en clave pública y se configura una sola vez.

Esta guía cubre iniciar el proceso a la escucha, hacerle push, aprobar un nuevo emisor en el primer contacto, automatizarlo y ejecutar el proceso a la escucha como servicio de systemd.

Antes de empezar

Todo lo de abajo es la CLI de relayium, así que instálala primero si aún no la tienes. En macOS o Linux, un solo comando deja un binario precompilado en tu PATH:

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

¿Prefieres elegir el archivo tú mismo, o estás en Windows? Coge un binario de la página de releases — relayium.com/cli lista todas las opciones de instalación (o go build -o relayium ./cmd/relayium si tienes Go).
relayium --version confirma que está instalada. Sáltate esto y los comandos de abajo solo imprimirán « command not found ».

Iniciar el proceso a la escucha (en el receptor)

En el servidor receptor, serve escucha los push y los escribe en un directorio. Se ejecuta de forma continua por defecto; añade --once para aceptar una sola transferencia y salir. No compartes nada de antemano: no hay huellas que copiar por adelantado:

# en el RECEPTOR
relayium serve --dir ~/inbox      # añade --once para una sola transferencia; --port para cambiar 9031

El proceso a la escucha procesa las conexiones de una en una y deposita los archivos bajo --dir.
El puerto por defecto es 9031; cámbialo con --port y ábrelo en tu cortafuegos.

Hacerle push (en el emisor)

Desde el servidor emisor, haz push a la dirección relayium:// del receptor. La primera conexión fija la huella del receptor; cada conexión posterior la verifica, y una huella cambiada se rechaza en lugar de aceptarse en silencio, de modo que una clave sustituida o un ataque de intermediario se detecta, no se confía en él. En el primer push, el emisor espera un momento mientras el receptor lo aprueba (siguiente paso).

# en el EMISOR
relayium push ./build.tar.zst relayium://receiver.example.com

# puerto distinto al de por defecto
relayium push ./build.tar.zst relayium://receiver.example.com:9040

Sin retransmisor y sin respaldo: si no se puede alcanzar el proceso a la escucha, el push falla; los bytes del archivo nunca se enrutan a través de nadie más.
El mismo motor de transferencia que los otros modos: reanudable, con una comprobación SHA-256 por archivo.

Aprobar al emisor en el primer push (en el receptor)

La primera vez que una máquina nueva hace push a tu proceso a la escucha, serve (en una terminal) te muestra de dónde viene y su huella y te pide que la apruebes, como el aviso de primera conexión de SSH, pero en el lado receptor:

# en el RECEPTOR, cuando una máquina nueva hace push:
Incoming push from 203.0.113.7:54021
  fingerprint: 74318e3b…
Accept and remember this peer? [y/N] y

Responde y y esa huella se recuerda en authorized_fingerprints; cada push posterior desde la misma máquina pasa entonces en silencio.
La huella es la identidad estable de una máquina (sobrevive a reinicios y cambios de IP), así que aprobar es un paso único por emisor.
El emisor, a su vez, aprende la clave del proceso a la escucha en la primera conexión (confianza en el primer uso) y la fija en known_hosts.

Automatizarlo (o ejecutarlo sin terminal)

Como una huella aprobada se recuerda, los push posteriores no necesitan aviso, así que relayium push encaja directamente en cron, un script de despliegue o CI para una sincronización de servidor a servidor cifrada, con integridad comprobada y reanudable. Cuando serve se ejecuta sin terminal (un servicio de systemd, una tubería) no puede preguntar, así que rechaza a los emisores desconocidos; autorízalos de antemano en su lugar. Obtén la huella con relayium id en el emisor, o cópiala de la línea « rejected unauthorized peer … » del registro de serve, y luego:

# en el RECEPTOR: autoriza a un emisor de antemano, sin aviso
relayium authorize 74318e3b...

Los archivos de identidad y confianza viven en ~/.config/relayium/ (se anulan con --config-dir, p. ej. /etc/relayium para un servicio).
authorize es idempotente: ejecutarlo de nuevo para la misma huella no hace nada.

Ejecutar el proceso a la escucha bajo systemd

Para una bandeja de entrada siempre activa, ejecuta serve como servicio de systemd. Apunta --config-dir a una ubicación fija como /etc/relayium para que la identidad sea estable entre reinicios, y deja que systemd la mantenga viva:

# /etc/systemd/system/relayium-serve.service
[Unit]
Description=Relayium daemon-direct listener
After=network-online.target

[Service]
ExecStart=/usr/local/bin/relayium serve --dir /srv/inbox --config-dir /etc/relayium
Restart=always
User=relayium

[Install]
WantedBy=multi-user.target

systemctl enable --now relayium-serve para iniciarlo y levantarlo al arrancar.
Mantén /etc/relayium/id.key legible solo para el usuario del servicio: relayium se niega a cargar una clave con permisos laxos.

Preguntas frecuentes

¿En qué se diferencia daemon directo de push por SSH?

push por SSH tuneliza la transferencia a través de tu conexión SSH y necesita una cuenta SSH en el remoto. daemon directo no necesita SSH ni cuenta: los dos servidores se autentican mutuamente por huella de certificado sobre TLS con anclaje, lo cual es más ligero cuando ambas máquinas son tuyas.

¿Tengo que copiar huellas a mano de un lado a otro?

No. En una terminal, serve te pide aprobar a cada nuevo emisor en su primer push —mostrando su dirección y su huella— y lo recuerda, así que los push posteriores son silenciosos. Solo recurres a relayium id o relayium authorize en configuraciones no interactivas como un servicio de systemd, donde no hay nadie para responder al aviso.

¿Dónde están los archivos de identidad y confianza?

En ~/.config/relayium/ por defecto (se anula con --config-dir). id.key / id.crt son la identidad persistente de este host, known_hosts guarda las huellas de los procesos a la escucha a los que has hecho push, y authorized_fingerprints es la lista de permitidos de emisores del proceso a la escucha.

¿Qué pasa si una huella cambia?

El push se rechaza y avisa. La clave del proceso a la escucha se fija en known_hosts en el primer uso, así que un cambio posterior —un host con clave regenerada o un ataque de intermediario— se rechaza en lugar de aceptarse en silencio. Elimina la línea de known_hosts solo si rotaste la clave a propósito.

¿Hay algún respaldo por retransmisor?

No. daemon directo asume una dirección de proceso a la escucha alcanzable; si no se puede establecer la conexión, falla. Nada se enruta nunca a través de Relayium como proxy: ese es el sentido de este modo.

Conecta dos de tus propios servidores para transferencias directas: sin retransmisor, sin SSH, sin código de emparejamiento.

Obtener la CLI