Transferts serveur à serveur avec la CLI Relayium (daemon direct)

Dernière mise à jour: 2026-07-08

Quand les deux machines vous appartiennent et que chacune connaît l'adresse de l'autre, SSH est une friction superflue et un rendez-vous n'est que du pur surcoût. Le daemon direct est fait exactement pour cela : un serveur écoute, l'autre pousse directement vers lui via une connexion TLS 1.3 épinglée. Pas de relais, pas de SSH, pas de code de jumelage — la confiance repose sur des clés publiques et se configure une seule fois.

Ce guide couvre le démarrage de l'écouteur, l'envoi vers celui-ci, l'approbation d'un nouvel émetteur au premier contact, l'automatisation, et l'exécution de l'écouteur en tant que service systemd.

Démarrer l'écouteur (sur le récepteur)

Sur le serveur récepteur, serve écoute les envois et les écrit dans un répertoire. Il tourne en continu par défaut ; ajoutez --once pour accepter un seul transfert puis s'arrêter. Vous n'avez rien à partager à l'avance — aucune empreinte à copier au préalable :

# on the RECEIVER
relayium serve --dir ~/inbox      # add --once for a single transfer; --port to change 9031

L'écouteur traite les connexions une par une et dépose les fichiers sous --dir.
Le port par défaut est 9031 ; changez-le avec --port et ouvrez-le sur votre pare-feu.

Envoyer vers l'écouteur (sur l'émetteur)

Depuis le serveur émetteur, envoyez vers l'adresse relayium:// du récepteur. La première connexion épingle l'empreinte du récepteur ; chaque connexion suivante la vérifie, et une empreinte modifiée est refusée plutôt qu'acceptée silencieusement — une clé remplacée ou une attaque de l'homme du milieu est ainsi détectée, pas approuvée. Lors du tout premier envoi, l'émetteur patiente un instant pendant que le récepteur l'approuve (étape suivante).

# on the SENDER
relayium push ./build.tar.zst relayium://receiver.example.com

# non-default port
relayium push ./build.tar.zst relayium://receiver.example.com:9040

Aucun relais et aucun repli : si l'écouteur n'est pas joignable, l'envoi échoue — les octets du fichier ne transitent jamais par qui que ce soit d'autre.
Le même moteur de transfert que les autres modes : reprenable, avec une vérification SHA-256 par fichier.

Approuver l'émetteur au premier envoi (sur le récepteur)

La première fois qu'une nouvelle machine envoie vers votre écouteur, serve (dans un terminal) vous montre d'où elle vient et son empreinte, puis vous demande de l'approuver — comme l'invite de première connexion de SSH, mais côté récepteur :

# on the RECEIVER, when a new sender pushes:
Incoming push from 203.0.113.7:54021
  fingerprint: 74318e3b…
Accept and remember this peer? [y/N] y

Répondez y et cette empreinte est mémorisée dans authorized_fingerprints ; chaque envoi ultérieur depuis la même machine passe alors silencieusement.
L'empreinte est l'identité stable d'une machine (elle survit aux redémarrages et aux changements d'IP), donc l'approbation n'est qu'une étape ponctuelle par émetteur.
L'émetteur, de son côté, découvre la clé de l'écouteur à la première connexion (confiance à la première utilisation) et l'épingle dans known_hosts.

Automatiser (ou exécuter sans terminal)

Comme une empreinte approuvée est mémorisée, les envois suivants ne demandent plus de confirmation — relayium push s'intègre donc directement dans cron, un script de déploiement ou la CI pour une synchronisation serveur à serveur chiffrée, vérifiée en intégrité et reprenable. Quand serve tourne sans terminal (un service systemd, un pipe), il ne peut pas demander confirmation et rejette donc les émetteurs inconnus ; autorisez-les plutôt à l'avance. Récupérez l'empreinte via relayium id côté émetteur, ou copiez-la depuis la ligne « rejected unauthorized peer … » du journal de serve, puis :

# on the RECEIVER: pre-authorize a sender without a prompt
relayium authorize 74318e3b...

Les fichiers d'identité et de confiance se trouvent dans ~/.config/relayium/ (à surcharger avec --config-dir, par exemple /etc/relayium pour un service).
authorize est idempotent — l'exécuter à nouveau pour la même empreinte ne fait rien.

Exécuter l'écouteur sous systemd

Pour une boîte de réception toujours active, exécutez serve en tant que service systemd. Pointez --config-dir vers un emplacement fixe comme /etc/relayium pour que l'identité reste stable entre les redémarrages, et laissez systemd le maintenir en vie :

# /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 pour le démarrer et le faire démarrer au boot.
Gardez /etc/relayium/id.key lisible uniquement par l'utilisateur du service — relayium refuse de charger une clé aux permissions trop permissives.

Questions fréquentes

En quoi le daemon direct diffère-t-il de push via SSH ?

push via SSH fait transiter le transfert par votre connexion SSH et nécessite un compte SSH sur la machine distante. Le daemon direct ne nécessite ni SSH ni compte — les deux serveurs s'authentifient mutuellement par empreinte de certificat via TLS épinglé, ce qui est plus léger quand les deux machines vous appartiennent.

Dois-je recopier les empreintes à la main ?

Non. Dans un terminal, serve vous invite à approuver chaque nouvel émetteur lors de son premier envoi — en affichant son adresse et son empreinte — et s'en souvient, si bien que les envois suivants sont silencieux. Vous n'avez recours à relayium id ou relayium authorize que pour des configurations non interactives, comme un service systemd, où personne n'est là pour répondre à l'invite.

Où se trouvent les fichiers d'identité et de confiance ?

Dans ~/.config/relayium/ par défaut (à surcharger avec --config-dir). id.key / id.crt sont l'identité persistante de cet hôte, known_hosts contient les empreintes des écouteurs vers lesquels vous avez envoyé, et authorized_fingerprints est la liste d'autorisation des émetteurs de l'écouteur.

Que se passe-t-il si une empreinte change ?

L'envoi est refusé et un avertissement s'affiche. La clé de l'écouteur est épinglée dans known_hosts à la première utilisation, donc un changement ultérieur — un hôte reclé, ou une attaque de l'homme du milieu — est rejeté plutôt qu'accepté silencieusement. Ne supprimez la ligne known_hosts que si vous avez intentionnellement fait tourner la clé.

Y a-t-il un repli vers un relais ?

Non. Le daemon direct suppose une adresse d'écouteur joignable ; si la connexion ne peut pas être établie, il échoue. Rien n'est jamais relayé via Relayium — c'est tout l'intérêt de ce mode.

Reliez deux de vos propres serveurs pour des transferts directs — sans relais, sans SSH, sans code de jumelage.

Obtenir la CLI