Dateien über die Kommandozeile empfangen

Zuletzt aktualisiert: 2026-08-06

Senden ist nur die halbe Geschichte — früher oder später bist du auf der Empfängerseite: Ein Kollege will dir eine Datei über das Internet übergeben, eine deiner eigenen Maschinen will sie an eine andere weiterreichen, oder du willst selbst etwas von einem Server holen, den du verwaltest. Die Relayium CLI deckt alle drei Fälle mit jeweils einem eigenen Befehl ab, und keiner davon braucht ein Konto.

Wähle receive, wenn jemand anderes per Pairing-Code zu dir pusht, serve, wenn du einen dauerhaften Eingangskorb willst, zu dem vertrauenswürdige Maschinen jederzeit pushen können, und pull, wenn du selbst zu einem Server greifst, in den du dich schon per SSH einloggen kannst.

Drei Wege zu empfangen, und wann welcher passt

Welchen Befehl du nutzt, hängt davon ab, wer die Übertragung startet und wie sich die beiden Maschinen kennen:

relayium receive <code> [destdir] — jemand sendet dir netzwerkübergreifend mit einem Pairing-Code, den dessen CLI erzeugt und dir außerhalb des Kanals mitgeteilt hat. Direkt peer-to-peer, mit einem SAS-Code zum Vergleichen.
relayium serve [--dir D] [--port N] [--once] [--allow-delete] — diese Maschine lauscht auf Daemon-Direct-Pushes über relayium://, standardmäßig auf Port 9031.
relayium pull [user@]host:src <dest> — du greifst per SSH auf einen Server zu, in den du dich schon einloggen kannst, und holst Dateien zurück.

receive: jemand sendet dir eine Datei über Netzwerke hinweg

Was du vor Schritt 1 brauchst

Die CLI auf diesem Rechner. relayium version gibt eine Versionszeile aus; antwortet die Shell mit command not found, ist sie hier noch nicht installiert.
Einen Sender, der gerade angemeldet und gerade am Terminal ist. Nur er braucht ein Konto — zum Empfangen meldest du dich nie an.
Die sechs Ziffern, über einen Nebenkanal. Sie leben fünf Minuten ab dem Moment, in dem seine CLI sie geprägt hat, also stimmt den Zeitpunkt vorher ab.
Einen Weg, ihm danach sechs weitere Ziffern vorzulesen: der SAS wird laut verglichen, nicht auf dem Bildschirm.
Die Gegenseite muss die CLI sein. Ein Browser kann einem CLI-Pairing-Code nicht beitreten — hast du nur einen, bitte um einen relayium up-Link.

Das ist die Empfangsseite von relayium send. Die andere Person führt auf ihrer Seite relayium send <path> aus (nach relayium login); ihre CLI erzeugt einen Code aus 6 Ziffern, gültig für 5 Minuten, und gibt ihn aus. Sie teilt ihn dir über einen Kanal mit, dem ihr beide vertraut — ein Anruf, eine Chatnachricht. Du führst receive mit diesem Code aus:

relayium receive 483920

# oder in ein bestimmtes Verzeichnis
relayium receive 483920 ./downloads

Stimm mit dem Sender ab, wann er send ausführt. Der Code läuft ab dem Prägen ab, nicht ab dem Moment, in dem du ihn bekommst.
Nimm die sechs Ziffern über einen Kanal entgegen, dem ihr beide traut — ein Anruf, ein Chatfenster, der Raum, in dem ihr sitzt.
Führ receive in dem Verzeichnis aus, in dem die Dateien landen sollen, oder gib eines explizit an.
```
relayium receive 483920
```
```
relayium receive 483920 ./downloads
```
Wenn beide Terminals einen Verifizierungscode zeigen, lies deinen laut vor und prüfe, ob er mit seinem übereinstimmt. Er ist nicht der Pairing-Code, und er ist das Einzige, was eine ausgetauschte Gegenstelle ausschließt.
Lass das Terminal in Ruhe, bis es zur Eingabeaufforderung zurückkehrt. Das ist eine laufende Sitzung: schließt eine Seite, stoppt die Übertragung.

So sieht ein erfolgreicher Empfang aus

Die Verbindung wird als direct gemeldet, und beide Terminals zeigen denselben Verifizierungscode. Unterschiedliche Codes sind das eine Ergebnis, das du nicht akzeptieren darfst — hör auf und kläre mit dem Sender, an welchem Rechner er sitzt.

$ relayium receive 483920
verification code (SAS): 271044 — not the pairing code; compare it on both ends to rule out a substituted endpoint
path: direct

Die Verbindung ist direkt, peer-to-peer und Ende-zu-Ende verschlüsselt; sobald sie steht, geben beide Terminals denselben SAS (Short Authentication String) aus. Vergleiche ihn außerhalb des Kanals mit dem Sender, um zu bestätigen, dass die angehefteten TLS-Zertifikatsfingerabdrücke nicht ausgetauscht wurden und der Rendezvous-Dienst keinen Endpunkt imitiert hat. Der SAS authentifiziert die Endpunkte; er beweist nicht jeden Netzwerk-Hop.
Ohne angegebenes Ziel landen die Dateien im aktuellen Verzeichnis.
Dieselbe Nur-direkt-Regel wie bei send: Findet sich kein direkter Pfad zwischen den beiden Netzwerken, schlägt die Übertragung fehl, statt über ein Relay geleitet zu werden.
Das ist das eigene Pairing-Code-Protokoll der CLI — CLI-Codes koppeln CLI mit CLI. Es arbeitet heute nicht mit dem Pairing-Code oder QR-Ablauf des Browsers auf relayium.com zusammen. Das könnte irgendwann kommen, ist aber momentan nicht etwas, worauf du dich verlassen kannst. Hast du nur einen Browser, bitte den Absender stattdessen um einen Download-Link via relayium up.
Der Empfänger braucht auf keinem Netzwerk je ein Konto. Nur der Absender meldet sich an, damit dessen CLI den Code erzeugen kann.

serve: diese Maschine zu einem lauschenden Eingangskorb machen

serve funktioniert umgekehrt: Statt dass du selbst aktiv wirst, pushen andere Maschinen direkt zu dir über relayium:// — gebaut für Maschinen, denen du schon vertraust, etwa dein eigener Laptop, der zu einem NAS pusht, oder ein Build-Server, der Artefakte auf einer Maschine ablegt, die dir gehört — über eine TLS-1.3-Verbindung mit Pinning, ohne SSH, ohne Rendezvous.

relayium serve

# ein bestimmtes Verzeichnis, ein bestimmter Port, Löschanfragen erlaubt
relayium serve --dir ~/incoming --port 9031 --allow-delete

Starte den Listener und nenne das Verzeichnis, in dem Pushes landen sollen.
```
relayium serve --dir ~/incoming
```
Beim ersten Push eines neuen Rechners zeigt serve dessen Adresse und Fingerprint und fragt nach. Einmal freigegeben, laufen spätere Pushes desselben Fingerprints stumm durch.
Soll dieser Listener ohne Terminal laufen, verlass dich nicht auf die Abfrage — niemand kann sie beantworten, und ein unbekannter Sender wird schlicht abgewiesen. Nimm stattdessen die Vorab-Freigabe aus dem nächsten Abschnitt.

Wenn eine neue Maschine zum ersten Mal zu dir pusht, zeigt dir serve (in einem Terminal laufend) ihre Adresse und ihren Fingerprint und bittet dich, sie einmalig zu genehmigen; danach laufen Pushes vom selben Fingerprint stillschweigend durch.
Ohne Terminal — ein systemd-Dienst, ein Skript ohne TTY — gibt es niemanden, den man fragen könnte, also wird ein unbekannter Pusher rundheraus abgelehnt. Genehmige ihn stattdessen im Voraus, mit dem Fingerprint, den der Pusher via relayium id ausgibt:

Vorab genehmigen für unbeaufsichtigtes serve

Für ein serve, das unbeaufsichtigt läuft (systemd, ein Hintergrundskript), lass den Pusher relayium id ausführen, um seinen Fingerprint auszugeben, und genehmige ihn dann von der Empfängerseite aus im Voraus:

relayium authorize <fingerprint>

--dir legt fest, wo Dateien landen (Standard: das aktuelle Verzeichnis); --once nimmt eine einzelne Übertragung an und beendet sich; --allow-delete erlaubt es einer eingehenden --delete-Anfrage (Spiegelung), hier tatsächlich Dateien zu löschen, und ist standardmäßig aus.
--config-dir (Standard ~/.config/relayium) ist der Ort, an dem die Identität dieses Hosts und seine Liste genehmigter Fingerprints liegen — überschreibe ihn, wenn du serve als dedizierten Dienst betreibst.

pull: selbst auf einen Server zugreifen, in den du dich per SSH einloggen kannst

pull ist das Spiegelbild von push: Statt darauf zu warten, dass dir jemand etwas sendet, greifst du über deinen bestehenden SSH-Zugang zu und holst Dateien zurück.

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

Prüfe, ob die Gegenstelle die CLI überhaupt hat. pull führt relayium drüben aus, und anders als push gibt es keinen tar-Fallback — fehlt das Binary, scheitert der ganze Befehl.
```
ssh user@host command -v relayium
```

Fehlt es, installiere es dort zuerst.

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

Hol die Dateien über deinen vorhandenen SSH-Zugang zurück. -i und -p verhalten sich wie bei ssh selbst.
```
relayium pull user@host:/path/to/files ./local-dest
```

Anders als push braucht pull immer relayium, das auf der Gegenseite bereits installiert ist — es gibt keinen tar-Fallback für das Pullen von einem blanken Server. Ist relayium dort noch nicht vorhanden, installiere es zuerst mit curl -fsSL https://relayium.com/install.sh | sh.
Dateien werden mit einer SHA-256-Prüfung pro Datei verifiziert und setzen bei Unterbrechung automatisch fort (mit --no-resume deaktivierbar).
-i und -p verhalten sich wie die eigenen -i/-p von ssh, für eine bestimmte Identitätsdatei oder einen bestimmten Port.

Wenn es nicht funktioniert

Fünf Fehler decken fast jeden misslungenen Empfang ab. Welcher Befehl lief, entscheidet, welcher davon greift, und zu jedem gibt es eine Zeile zum Lesen oder einen Befehl zum Ausführen.

Symptom, Prüfung, Lösung

Du gibst den Code ein und der Rendezvous weist ihn ab.

relayium receive 483920
# the rendezvous refuses the code

Fast immer sind die fünf Minuten um — der Code verfällt ab dem Prägen durch die CLI des Senders, nicht ab dem Moment, in dem du ihn erfahren hast. Lass ihn send erneut ausführen und dir die frischen Ziffern sofort vorlesen. Eine vertippte Ziffer sieht von hier aus identisch aus, also lies sie zurück, bevor du auf Ablauf tippst.

Die Übertragung läuft durch, aber du findest die Dateien nicht.

relayium receive 483920 ./downloads

Ohne Zielangabe schreibt receive in das Verzeichnis, aus dem du es gestartet hast — selten das, in dem du gesucht hast. Gib eines explizit an, oder führ vorher pwd aus.

Es scheitert mit "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?): …

Der CLI-Pairing-Pfad ist bewusst nur direkt: gibt es keine direkte Route, scheitert er, statt deine Datei über ein Relay zu schicken. Auf deiner Seite ist da nichts zu machen. Bitte den Sender stattdessen um einen relayium up-Downloadlink, oder nutzt zwischen Rechnern, die euch beiden gehören, daemon-direct oder push über SSH.

pull scheitert sofort und beklagt, relayium sei nicht gefunden worden.

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

pull führt relayium auf der Gegenstelle aus — dort ist sie der Sender — und es gibt keinen tar-Fallback wie bei push. Installiere die CLI zuerst drüben und starte den Pull neu.

Ein Rechner pusht an deinen serve-Listener und wird abgewiesen, ohne dass du je gefragt wurdest.

relayium serve --dir ~/incoming

Die Abfrage existiert nur, wenn serve ein Terminal hat. Unter systemd, in einem Skript oder hinter einer Pipe ist niemand da, also wird ein unbekannter Fingerprint direkt abgelehnt. Lass den Sender relayium id ausführen und gib ihn hier mit relayium authorize <Fingerprint> frei — mit demselben --config-dir, unter dem der Listener läuft.

Häufige Fragen

Brauche ich ein Konto, um Dateien zu empfangen?

Nein. Alle drei Wege — receive, serve und pull — sind vollständig kostenlos und brauchen auf deiner Seite kein Relayium-Konto. Die einzige Anmeldung überhaupt ist die des Absenders im receive-Fall, damit dessen CLI den Pairing-Code erzeugen kann.

Arbeitet relayium receive mit dem Pairing-Code des Browsers zusammen?

Nein. Das Pairing-Code-Protokoll der CLI ist getrennt vom Join-Link- und QR-Ablauf des Browsers auf relayium.com — sie verwenden unterschiedliche Handshakes und sprechen heute nicht miteinander, ein CLI-Code koppelt also nur mit einer anderen CLI. Das steht auf der Roadmap, ist aber noch nichts, worauf du dich verlassen kannst. Bis dahin will ein Empfänger im Browser einen Link aus relayium up statt eines Codes.

Was passiert, wenn eine unbekannte Maschine zu meinem serve-Listener pusht?

In einem Terminal wirst du bei ihrem ersten Push aufgefordert, sie anhand von Adresse und Fingerprint zu genehmigen, und die Genehmigung wird gespeichert. Ohne Terminal — ein systemd-Dienst, ein Cron-Job — gibt es niemanden, den man fragen könnte, also wird ein unbekannter Pusher abgelehnt; genehmige ihn vorher mit relayium authorize <fingerprint>.

Kann ich von einem Server pullen, auf dem relayium nicht installiert ist?

Nein. pull braucht immer relayium auf der Gegenseite; es gibt keinen tar-Fallback wie bei push. Installiere relayium dort zuerst.

Wo speichert relayium meine Identität und vertrauenswürdige Gegenstellen?

Standardmäßig in ~/.config/relayium — überschreibe den Ort mit --config-dir bei jedem Befehl, der mit Identität oder Vertrauen zu tun hat.

Bereit für deine erste Übertragung? Installiere die CLI und wähle receive, serve oder pull.

CLI holen