Recevoir des fichiers depuis la ligne de commande

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

Envoyer n'est que la moitié de l'histoire — tôt ou tard, c'est vous qui recevez : un collègue veut vous remettre un fichier par Internet, l'une de vos machines veut le transmettre à une autre, ou vous voulez aller chercher quelque chose sur un serveur que vous administrez. La CLI Relayium couvre ces trois cas avec une commande différente pour chacun, et aucune ne nécessite de compte.

Choisissez receive quand quelqu'un d'autre vous envoie via un code d'appairage, serve quand vous voulez une boîte de réception permanente vers laquelle des machines de confiance peuvent envoyer à tout moment, et pull quand c'est vous qui allez chercher sur un serveur où vous pouvez déjà vous connecter en SSH.

Trois façons de recevoir, et quand utiliser chacune

La commande à exécuter dépend de qui déclenche le transfert et de la façon dont les deux machines se connaissent :

relayium receive <code> [destdir] — quelqu'un vous envoie à travers les réseaux avec un code d'appairage que sa CLI a généré et vous a communiqué hors bande. Pair-à-pair direct, avec un code SAS à comparer.
relayium serve [--dir D] [--port N] [--once] [--allow-delete] — cette machine écoute les envois en daemon direct via relayium://, sur le port 9031 par défaut.
relayium pull [user@]host:src <dest> — vous allez chercher, via SSH, sur un serveur où vous pouvez déjà vous connecter, et vous récupérez des fichiers.

receive : quelqu'un vous envoie un fichier à travers les réseaux

Ce qu'il vous faut avant l'étape 1

La CLI sur cette machine. relayium version affiche un numéro de version ; si le shell répond command not found, elle n'y est pas encore installée.
Un expéditeur connecté et devant son terminal maintenant. Lui seul a besoin d'un compte — vous ne vous connectez jamais pour recevoir.
Les six chiffres, transmis hors bande. Ils vivent cinq minutes à partir du moment où sa CLI les a générés, alors convenez d'abord du moment.
Un moyen de lui relire six autres chiffres ensuite : le SAS se compare à voix haute, pas à l'écran.
L'autre extrémité doit être la CLI. Un navigateur ne peut pas rejoindre un code d'appairage CLI — si c'est tout ce que vous avez, demandez plutôt un lien relayium up.

C'est le pendant côté réception de relayium send. L'autre personne exécute relayium send <path> de son côté (après relayium login) ; sa CLI génère un code de 6 chiffres, valable 5 minutes, et l'affiche. Elle vous le communique par un canal auquel vous faites tous deux confiance — un appel, un message. Vous exécutez receive avec ce code :

relayium receive 483920

# ou vers un répertoire précis
relayium receive 483920 ./downloads

Convenez avec l'expéditeur du moment où il lancera send. Le code commence à expirer dès sa génération, pas dès que vous le recevez.
Récupérez les six chiffres par un canal auquel vous faites confiance tous les deux — un appel, une fenêtre de discussion, la pièce où vous êtes.
Lancez receive depuis le répertoire où les fichiers doivent atterrir, ou indiquez-en un explicitement.
```
relayium receive 483920
```
```
relayium receive 483920 ./downloads
```
Quand les deux terminaux affichent un code de vérification, lisez le vôtre à voix haute et vérifiez qu'il correspond au sien. Ce n'est pas le code d'appairage, et c'est la seule chose qui écarte une extrémité substituée.
Ne touchez plus au terminal jusqu'à ce qu'il revienne à l'invite. C'est une session en direct : fermer l'une des extrémités arrête le transfert.

À quoi ressemble une réception réussie

La connexion est annoncée comme direct, et les deux terminaux affichent le même code de vérification. Des codes différents sont le seul résultat que vous ne devez pas accepter — arrêtez-vous et vérifiez avec l'expéditeur sur quelle machine il se trouve.

$ 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 connexion est directe, pair-à-pair et chiffrée de bout en bout ; une fois connectés, les deux terminaux affichent le même SAS (short authentication string). Comparez-le hors bande avec l'expéditeur pour confirmer que les empreintes des certificats TLS épinglés n'ont pas été substituées et que le service de rendez-vous n'a usurpé aucune extrémité. Le SAS authentifie les extrémités ; il ne prouve pas chaque saut réseau.
Sans destination indiquée, les fichiers atterrissent dans le répertoire courant.
Même règle de connexion directe uniquement que pour send : si aucun chemin direct n'est trouvé entre les deux réseaux, le transfert échoue plutôt que de transiter par un relais.
C'est le protocole de code d'appairage propre à la CLI — un code CLI ne s'appaire qu'avec une autre CLI. Il n'est pas interopérable aujourd'hui avec le code d'appairage ou le flux QR du navigateur sur relayium.com ; c'est un ajout possible à l'avenir, pas encore quelque chose sur quoi compter. Si vous n'avez qu'un navigateur, demandez plutôt à l'expéditeur un lien de téléchargement relayium up.
Le destinataire n'a jamais besoin de compte, quel que soit le réseau. Seul l'expéditeur se connecte, pour que sa CLI puisse générer le code.

serve : transformer cette machine en boîte de réception à l'écoute

serve fonctionne dans l'autre sens : au lieu que vous alliez chercher, d'autres machines vous envoient directement via relayium:// — conçu pour des machines en qui vous avez déjà confiance, comme votre propre ordinateur portable qui envoie vers un NAS, ou un serveur de build qui dépose des artefacts sur une machine qui vous appartient — via une connexion TLS 1.3 avec épinglage, sans SSH, sans rendez-vous.

relayium serve

# un répertoire et un port précis, en autorisant les requêtes de suppression
relayium serve --dir ~/incoming --port 9031 --allow-delete

Démarrez l'écouteur en nommant le répertoire où les envois doivent atterrir.
```
relayium serve --dir ~/incoming
```
Au premier envoi d'une machine inconnue, serve affiche son adresse et son empreinte et vous demande confirmation. Une fois approuvée, les envois suivants de cette empreinte passent sans rien dire.
Si cet écouteur doit tourner sans terminal, ne comptez pas sur cette demande — personne n'est là pour y répondre, et un expéditeur non reconnu est refusé d'emblée. Utilisez plutôt l'autorisation préalable décrite à la section suivante.

La première fois qu'une nouvelle machine vous envoie quelque chose, serve (exécuté dans un terminal) affiche son adresse et son empreinte et vous demande de l'approuver une fois ; ensuite, les envois de la même empreinte passent silencieusement.
Sans terminal — un service systemd, un script sans TTY — il n'y a personne à qui demander, donc un émetteur inconnu est rejeté d'emblée. Autorisez-le plutôt à l'avance, en utilisant l'empreinte que l'émetteur affiche avec relayium id :

Autoriser à l'avance pour un serve sans surveillance

Pour un serve qui tourne sans surveillance (systemd, un script en arrière-plan), demandez à l'émetteur d'exécuter relayium id pour afficher son empreinte, puis approuvez-la à l'avance côté récepteur :

relayium authorize <fingerprint>

--dir définit où les fichiers atterrissent (par défaut le répertoire courant) ; --once accepte un seul transfert puis s'arrête ; --allow-delete permet à une requête --delete (miroir) entrante de réellement supprimer des fichiers ici, et est désactivé par défaut.
--config-dir (par défaut ~/.config/relayium) est l'endroit où se trouvent l'identité de cet hôte et sa liste d'empreintes autorisées — surchargez-le si vous exécutez serve comme service dédié.

pull : aller chercher sur un serveur où vous pouvez déjà vous connecter en SSH

pull est le miroir de push : au lieu d'attendre que quelqu'un vous envoie quelque chose, vous allez chercher via votre accès SSH existant et récupérez des fichiers.

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

Vérifiez que la machine distante a bien la CLI. pull exécute relayium à l'autre bout et, contrairement à push, il n'existe aucun repli sur tar : un binaire manquant fait échouer toute la commande.
```
ssh user@host command -v relayium
```

S'il manque, installez-le d'abord là-bas.

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

Rapatriez les fichiers via votre accès SSH existant. -i et -p se comportent comme ceux de ssh.
```
relayium pull user@host:/path/to/files ./local-dest
```

Contrairement à push, pull a toujours besoin de relayium déjà installé sur la machine distante — il n'y a pas de repli tar pour un pull depuis un serveur nu. Si relayium n'y est pas encore, installez-le d'abord avec curl -fsSL https://relayium.com/install.sh | sh.
Les fichiers sont vérifiés par un contrôle SHA-256 par fichier et reprennent automatiquement en cas d'interruption (ajoutez --no-resume pour désactiver).
-i et -p se comportent comme les -i/-p de ssh lui-même, pour un fichier d'identité ou un port spécifique.

Quand ça ne marche pas

Cinq pannes couvrent presque toutes les réceptions ratées. La commande que vous exécutiez détermine laquelle s'applique, et chacune se tranche par une ligne à lire ou une commande à exécuter.

Symptôme, vérification, correction

Vous saisissez le code et le rendez-vous le refuse.

relayium receive 483920
# the rendezvous refuses the code

Presque toujours les cinq minutes sont écoulées — le code expire à partir de sa génération par la CLI de l'expéditeur, pas à partir du moment où on vous l'a donné. Demandez-lui de relancer send et de vous lire les chiffres frais dans la foulée. Un chiffre mal tapé est indiscernable d'ici, alors relisez-le-lui avant de conclure à l'expiration.

Le transfert se termine mais vous ne trouvez pas les fichiers.

relayium receive 483920 ./downloads

Sans destination, receive écrit dans le répertoire depuis lequel vous l'avez lancé, rarement celui où vous cherchiez. Indiquez-en un explicitement, ou lancez pwd d'abord.

Il échoue avec « no direct connection to the peer (both ends behind strict NAT?) ».

relayium receive 483920
# no direct connection to the peer (both ends behind strict NAT?): …

Le chemin d'appairage de la CLI est délibérément direct uniquement : faute de route directe, il échoue plutôt que de faire transiter votre fichier par un relais. Rien de votre côté n'y changera quoi que ce soit. Demandez plutôt à l'expéditeur un lien de téléchargement relayium up, ou, entre machines que vous contrôlez tous les deux, passez par le daemon direct ou par push via SSH.

pull échoue immédiatement en signalant que relayium est introuvable.

ssh user@host command -v relayium
# (no output)

pull exécute relayium sur la machine distante — c'est elle l'expéditeur dans cet échange — et il n'y a pas de repli sur tar comme pour push. Installez d'abord la CLI là-bas, puis relancez le pull.

Une machine pousse vers votre écouteur serve et se fait refuser sans qu'on vous ait jamais demandé quoi que ce soit.

relayium serve --dir ~/incoming

Cette demande n'existe que si serve dispose d'un terminal. Sous systemd, dans un script ou derrière un tube, il n'y a personne à qui demander, donc une empreinte inconnue est refusée d'emblée. Faites exécuter relayium id à l'expéditeur et autorisez-la ici avec relayium authorize <empreinte>, sous le même --config-dir que l'écouteur.

Questions fréquentes

Ai-je besoin d'un compte pour recevoir des fichiers ?

Non. Les trois méthodes — receive, serve et pull — sont entièrement gratuites et ne nécessitent aucun compte Relayium de votre côté. La seule connexion où que ce soit est celle de l'expéditeur en mode receive, pour que sa CLI puisse générer le code d'appairage.

relayium receive est-il interopérable avec le code d'appairage du navigateur ?

Non. Le protocole de code d'appairage de la CLI est distinct du flux de lien de participation et de QR code du navigateur sur relayium.com — ils utilisent des poignées de main différentes et ne communiquent pas entre eux aujourd'hui, donc un code CLI ne s'appaire qu'avec une autre CLI. C'est sur la feuille de route, mais ce n'est pas encore quelque chose sur quoi compter. En attendant, un destinataire sur navigateur veut un lien relayium up plutôt qu'un code.

Que se passe-t-il si une machine inconnue envoie vers mon processus serve à l'écoute ?

Dans un terminal, on vous demande de l'approuver par son adresse et son empreinte lors de son premier envoi, et l'approbation est mémorisée. Sans terminal — un service systemd, une tâche cron — il n'y a personne à qui demander, donc un émetteur inconnu est rejeté ; autorisez-le d'abord avec relayium authorize <fingerprint>.

Puis-je faire un pull depuis un serveur où relayium n'est pas installé ?

Non. pull a toujours besoin de relayium côté distant ; il n'y a pas de repli tar comme pour push. Installez d'abord relayium là-bas.

Où relayium conserve-t-il mon identité et les pairs de confiance ?

Par défaut dans ~/.config/relayium — surchargez cet emplacement avec --config-dir sur toute commande touchant à l'identité ou à la confiance.

Prêt à recevoir votre premier transfert ? Installez la CLI et choisissez receive, serve ou pull.

Obtenir la CLI