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

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

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 avec épinglage. Pas de relais, pas de SSH, pas de code d'appairage — la confiance repose sur des clés publiques et se configure une seule fois.

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

Avant de commencer

Tout ci-dessous passe par la CLI relayium, alors installez-la d'abord si ce n'est pas fait. Sous macOS ou Linux, une commande place un binaire précompilé dans votre PATH :

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

Vous préférez choisir le fichier vous-même, ou sous Windows ? Récupérez un binaire depuis la page des releases — relayium.com/cli liste toutes les options (avec Go, go build -o relayium ./cmd/relayium).
relayium --version confirme l'installation. Sans cela, les commandes ci-dessous affichent seulement « command not found ».

Démarrer le processus à l'écoute (sur le récepteur)

Ce qu'il vous faut

Deux machines qui vous appartiennent, l'adresse du récepteur étant joignable depuis l'émetteur. Un nom d'hôte ou une simple IP conviennent.
relayium des deux côtés. Le daemon-direct ne parle que le protocole natif, donc aucun repli tar ne rattrapera ici une installation manquante.
Le port du processus à l'écoute ouvert à l'émetteur — 9031/TCP tant que vous ne le changez pas — dans le pare-feu de l'hôte et dans tout groupe de sécurité cloud.
Un terminal sur le récepteur pour le premier envoi, afin de répondre à la demande d'approbation. Sans terminal, autorisez plutôt l'émetteur à l'avance (voir plus bas).

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 :

Créez le répertoire dans lequel les envois doivent atterrir.
```
mkdir -p ~/inbox
```
N'ouvrez le port du processus à l'écoute qu'à l'émetteur. Remplacez 203.0.113.7 par l'adresse de l'émetteur lui-même — son IP publique, ou son IP privée si les deux serveurs partagent un réseau — et restreignez le groupe de sécurité cloud à cette même source plutôt qu'à tout l'internet.
```
sudo ufw allow from 203.0.113.7 to any port 9031 proto tcp
```
Démarrez le processus à l'écoute dans un terminal, pour que quelqu'un puisse répondre à la demande d'approbation au premier envoi. --once accepte un seul transfert puis quitte, --port le déplace hors de 9031.
```
relayium serve --dir ~/inbox
```

À quoi ressemble un processus à l'écoute qui tourne

serve annonce l'adresse sur laquelle il écoute, le répertoire dans lequel il écrit, et l'empreinte propre de cet hôte. Tant qu'aucun pair n'est approuvé, il précise aussi qu'il posera la question pour chaque nouveau.

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

Le processus à l'écoute 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 le processus à l'écoute (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).

Lancez l'envoi depuis le serveur émetteur. À la toute première connexion, il s'arrête précisément ici, le temps que le récepteur l'approuve.
```
relayium push ./build.tar.zst relayium://receiver.example.com
```
Répondez à la demande sur le récepteur, c'est la section suivante. L'envoi se termine ensuite tout seul, et les envois suivants ne s'arrêtent plus jamais ici.
Ajoutez un port lorsque le processus à l'écoute n'est pas sur 9031.
```
relayium push ./build.tar.zst relayium://receiver.example.com:9040
```

À quoi ressemble un envoi réussi

Au premier contact, l'émetteur apprend puis épingle l'empreinte du processus à l'écoute, et transfère. Le récepteur enregistre l'empreinte de l'émetteur et annonce le nombre de fichiers et d'octets.

# 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…

Aucun relais et aucun repli : si le processus à l'écoute 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 : avec reprise, et 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 processus à l'écoute, 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 :

# sur le RÉCEPTEUR, quand un nouvel émetteur envoie :
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é du processus à l'écoute à 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 avec reprise. 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 :

# sur le RÉCEPTEUR : autoriser un émetteur à l'avance, sans invite
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 le processus à l'écoute 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 démarrage.
Gardez /etc/relayium/id.key lisible uniquement par l'utilisateur du service — relayium refuse de charger une clé aux permissions trop permissives.

Quand un envoi ne passe pas

La joignabilité et la confiance sont les deux premières choses à vérifier : ss -tinp sur l'émetteur dit si le processus à l'écoute a seulement été atteint, et relayium authorize sur le récepteur accorde à un émetteur refusé la confiance qui lui manque. Ce ne sont pas les seules façons dont un envoi peut échouer — un récepteur à court d'espace disque, un répertoire de réception où son utilisateur ne peut pas écrire, ou un fichier transféré qui rate son contrôle d'intégrité se signalent tous eux-mêmes — lisez donc l'erreur que vous avez sous les yeux plutôt que de supposer qu'il s'agit de l'un des quatre cas ci-dessous.

Symptôme, vérification, correction

L'envoi reste immobile, puis échoue sur une erreur de connexion.

# sur l'ÉMETTEUR, pendant que l'envoi tourne — lancez-la deux fois, à quelques secondes d'intervalle
ss -tinp dst :9031
# ESTAB    le processus à l'écoute a été atteint ; cela ne dit rien de la progression
# SYN-SENT rien n'a répondu sur ce port

SYN-SENT signifie que les paquets n'ont jamais atteint une socket à l'écoute. Vérifiez sur le récepteur que serve tourne, avec ss -tlnp | grep 9031, puis ouvrez 9031/TCP à l'émetteur dans le pare-feu de l'hôte et dans le groupe de sécurité cloud. ESTAB ne prouve que l'accessibilité — une socket établie peut rester inactive ou bloquée —, donc pour distinguer ce qui avance de ce qui est coincé, relancez la vérification à quelques secondes d'intervalle et comparez le compteur bytes_acked que -i affiche pour cette socket. Il n'y a aucune voie de relais ici, donc un processus à l'écoute injoignable est un échec net et non un ralentissement.

Le journal de serve indique « rejected unauthorized peer … » et l'envoi échoue.

# sur l'ÉMETTEUR
relayium id
# 74318e3b…

# sur le RÉCEPTEUR
relayium authorize 74318e3b…

serve n'avait aucun terminal à qui demander — une unité systemd, un tube — donc une empreinte inconnue est refusée plutôt qu'acceptée. Autorisez-la à l'avance : l'empreinte de la ligne de refus est exactement celle qu'affiche relayium id sur l'émetteur, et authorize est idempotent.

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

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

Le processus à l'écoute a présenté une clé différente de celle épinglée au premier contact. Si vous avez fait tourner cette clé volontairement, supprimez la ligne correspondante de known_hosts et relancez l'envoi. Sinon, laissez la ligne en place et cherchez pourquoi la clé a changé avant d'envoyer quoi que ce soit.

L'unité systemd meurt au démarrage sur une erreur de permissions non sûres.

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 refuse de charger une clé privée lisible par quelqu'un d'autre que son propriétaire, la même règle qu'applique ssh. Lancez chmod 600 sur le chemin nommé par l'erreur, assurez-vous qu'il appartient à l'utilisateur du service, et redémarrez l'unité.

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 avec épinglage, 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 processus à l'écoute vers lesquels vous avez envoyé, et authorized_fingerprints est la liste d'autorisation des émetteurs du processus à l'écoute.

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

L'envoi est refusé et un avertissement s'affiche. La clé du processus à l'écoute est épinglée dans known_hosts à la première utilisation, donc un changement ultérieur — un hôte dont la clé a été régénérée, 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 effectué une rotation de clé.

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

Non. Le daemon-direct suppose une adresse de processus à l'écoute 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 d'appairage.

Obtenir la CLI