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

Última actualización: 2026-09-01

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)

Lo que necesitas

Dos máquinas bajo tu control, con la dirección del receptor alcanzable desde el emisor. Vale un nombre de host o una IP pelada.
relayium en los dos extremos. El daemon directo solo habla el protocolo nativo, así que aquí no hay ninguna alternativa con tar que rescate una instalación ausente.
El puerto del proceso a la escucha abierto al emisor —9031/TCP mientras no lo cambies— tanto en el cortafuegos del host como en cualquier grupo de seguridad en la nube.
Un terminal en el receptor para el primer push, para poder responder a la petición de aprobación. Sin terminal, autoriza al emisor de antemano (más abajo).

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:

Crea el directorio donde deben aterrizar los envíos.
```
mkdir -p ~/inbox
```
Abre el puerto del proceso a la escucha solo al emisor. Sustituye 203.0.113.7 por la dirección del propio emisor — su IP pública, o la privada si los dos servidores comparten red — y acota el grupo de seguridad en la nube a esa misma fuente en vez de a todo internet.
```
sudo ufw allow from 203.0.113.7 to any port 9031 proto tcp
```
Arranca el proceso a la escucha en un terminal, para que haya alguien que responda a la petición de aprobación en el primer push. Con --once acepta una sola transferencia y sale; con --port lo mueves fuera de 9031.
```
relayium serve --dir ~/inbox
```

Cómo se ve un proceso a la escucha en marcha

serve indica la dirección a la que se ha enlazado, el directorio en el que escribe y la huella propia de este host. Mientras no haya pares aprobados, avisa además de que preguntará por cada uno nuevo.

relayium serve --dir ~/inbox
no authorized peers yet — you'll be asked to approve each new peer on its first push.
relayium serve: listening on [::]:9031, receiving into /home/you/inbox (fingerprint 5c1d9f04…)

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).

Lanza el push desde el servidor emisor. En la primerísima conexión se detiene justo aquí mientras el receptor lo aprueba.
```
relayium push ./build.tar.zst relayium://receiver.example.com
```
Responde a la petición en el receptor: es la sección siguiente. Después el push termina solo, y los push posteriores ya no se detienen nunca aquí.

Añade un puerto cuando el proceso a la escucha no esté en 9031.

relayium push ./build.tar.zst relayium://receiver.example.com:9040

Cómo se ve un push correcto

En el primer contacto el emisor aprende y fija la huella del proceso a la escucha, y luego transfiere. El receptor anota la huella de quien empuja e informa del número de archivos y de bytes.

# on the SENDER, first contact
learned receiver.example.com:9031 5c1d9f04… (added to known_hosts)
  build.tar.zst (48213004 bytes)

# on the RECEIVER
authorized 74318e3b… (added to /home/you/.config/relayium/authorized_fingerprints)
received 1 file(s), 48213004 bytes from 74318e3b…

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: cada archivo se comprueba con un SHA-256 por archivo y se coloca en un área temporal antes de instalarlo. push no reanuda, ni aquí ni por SSH: rechaza un destino que ya existe. Una ejecución interrumpida se termina enviando las rutas que faltan, o con relayium sync, que continúa un archivo parcial y que este proceso a la escucha respeta salvo que se haya arrancado con --no-resume.

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 un script de despliegue o CI para una entrega de servidor a servidor cifrada y con integridad comprobada. Para un trabajo programado que escribe en el mismo directorio, usa relayium sync en su lugar: push rechaza un destino que ya existe, así que un push repetido hacia una ruta fija tiene éxito una vez y se rechaza después. 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 --config-dir /etc/relayium 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.

Cuando un push no llega

La accesibilidad y la confianza son lo primero que hay que comprobar: ss -tinp en el emisor dice si el proceso a la escucha llegó siquiera a ser alcanzado, y relayium authorize en el receptor le da a un emisor rechazado la confianza que le falta. No son las únicas formas en que un push puede fallar: un receptor sin espacio en disco, un directorio de entrada en el que su usuario no puede escribir o un archivo transferido que no supera su comprobación de integridad se anuncian todos por su cuenta, así que lee el error que tienes delante en vez de dar por hecho que es uno de los cuatro de abajo.

Síntoma, comprobación, solución

El push se queda quieto y luego falla con un error de conexión.

# en el EMISOR, mientras el push está en marcha — ejecútalo dos veces, con unos segundos de diferencia
ss -tinp dst :9031
# ESTAB    se alcanzó el proceso a la escucha; no dice nada del progreso
# SYN-SENT nada respondió en ese puerto

SYN-SENT significa que los paquetes nunca llegaron a un socket a la escucha. Comprueba en el receptor que serve está en marcha con ss -tlnp | grep 9031, y luego abre 9031/TCP al emisor en el cortafuegos del host y en el grupo de seguridad de la nube. ESTAB solo demuestra alcanzabilidad — un socket establecido puede quedarse inactivo o atascado —, así que para distinguir lo que avanza de lo que está parado ejecuta la comprobación dos veces con unos segundos de diferencia y compara el contador bytes_acked que -i imprime para ese socket. Aquí no hay ninguna vía de retransmisor, así que un proceso a la escucha inalcanzable es un fallo rotundo, no una lentitud.

El registro de serve dice «rejected unauthorized peer …» y el push falla.

# en el EMISOR
relayium id
# 74318e3b…

# en el RECEPTOR
relayium authorize --config-dir /etc/relayium 74318e3b…

serve no tenía ningún terminal al que preguntar —una unidad de systemd, una tubería—, así que una huella desconocida se rechaza en lugar de aceptarse. Autorízala de antemano: la huella de la línea de rechazo es exactamente la que imprime relayium id en el emisor, y authorize es idempotente.

«fingerprint mismatch for receiver.example.com:9031».

grep receiver.example.com ~/.config/relayium/known_hosts

El proceso a la escucha presentó una clave distinta de la fijada en el primer contacto. Si rotaste esa clave a propósito, borra la línea correspondiente de known_hosts y vuelve a hacer push. Si no fuiste tú, deja la línea en paz y averigua por qué cambió la clave antes de enviar nada.

La unidad de systemd muere al arrancar con un error de permisos inseguros.

systemctl status relayium-serve
# secure: /etc/relayium/id.key has insecure permissions 0644; run: chmod 600 /etc/relayium/id.key
ls -l /etc/relayium/id.key

relayium se niega a cargar una clave privada que pueda leer alguien más que su propietario, la misma regla que aplica ssh. Ejecuta chmod 600 sobre la ruta que nombra el error, asegúrate de que pertenece al usuario del servicio y reinicia la unidad.

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