Relayium

Server-zu-Server-Übertragungen mit der Relayium CLI (daemon-direct)

Zuletzt aktualisiert: 2026-08-05

Wenn beide Maschinen dir gehören und jede die Adresse der anderen kennt, ist SSH zusätzliche Reibung und ein Rendezvous reiner Overhead. daemon-direct ist genau dafür gebaut: Ein Server lauscht, der andere pusht direkt dorthin über eine TLS-1.3-Verbindung mit Pinning. Kein Relay, kein SSH, kein Pairing-Code — das Vertrauen basiert auf Public Keys und wird einmal eingerichtet.

Diese Anleitung behandelt das Starten des Listeners, das Pushen dorthin, das Genehmigen eines neuen Pushers beim ersten Kontakt, die Automatisierung und den Betrieb des Listeners als systemd-Dienst.

Bevor du loslegst

Alles unten ist die relayium-CLI, installiere sie also zuerst, falls noch nicht geschehen. Unter macOS oder Linux legt ein Befehl ein vorgebautes Binary in deinen PATH:

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

Den Listener starten (auf dem Empfänger)

Was du brauchst

  • Zwei Rechner, die dir gehören, und die Adresse des Empfängers vom Sender aus erreichbar. Ein Hostname oder eine nackte IP tun es beide.
  • relayium auf beiden Seiten. Daemon-direct spricht nur das native Protokoll, hier rettet dich also kein tar-Fallback, wenn die Installation fehlt.
  • Den Port des Listeners für den Sender offen — 9031/TCP, solange du ihn nicht änderst — in der Host-Firewall und in jeder Cloud-Sicherheitsgruppe.
  • Ein Terminal auf dem Empfänger für den ersten Push, damit du die Genehmigungsfrage beantworten kannst. Ohne Terminal autorisierst du den Sender stattdessen vorab (siehe unten).

Auf dem empfangenden Server lauscht serve auf Pushes und schreibt sie in ein Verzeichnis. Standardmäßig läuft es dauerhaft; mit --once nimmt es eine einzelne Übertragung an und beendet sich. Du musst nichts vorab teilen — keine Fingerprints, die du im Voraus kopieren müsstest:

  1. Leg das Verzeichnis an, in dem Pushes landen sollen.

    mkdir -p ~/inbox

  2. Öffne den Port des Listeners nur für den Sender. Ersetz 203.0.113.7 durch die Adresse des Senders selbst — seine öffentliche IP, oder seine private, wenn beide Server im selben Netz hängen — und grenz die Cloud-Sicherheitsgruppe auf dieselbe Quelle ein statt auf das ganze Internet.

    sudo ufw allow from 203.0.113.7 to any port 9031 proto tcp

  3. Starte den Listener in einem Terminal, damit beim ersten Push jemand die Genehmigungsfrage beantworten kann. --once nimmt eine einzelne Übertragung und beendet sich, --port bringt ihn weg von 9031.

    relayium serve --dir ~/inbox

So sieht ein laufender Listener aus

serve nennt die Adresse, an die er gebunden hat, das Verzeichnis, in das er schreibt, und den eigenen Fingerabdruck dieses Hosts. Solange keine Peers genehmigt sind, sagt er außerdem, dass er zu jedem neuen nachfragen wird.

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

Zum Listener pushen (auf dem Sender)

Vom sendenden Server aus, push zur relayium://-Adresse des Empfängers. Die erste Verbindung pinnt den Fingerprint des Empfängers; jede folgende Verbindung überprüft ihn, und ein geänderter Fingerprint wird abgelehnt statt stillschweigend akzeptiert — ein ausgetauschter Schlüssel oder ein Man-in-the-Middle wird so erkannt, nicht vertraut. Beim allerersten Push wartet der Sender einen Moment, während der Empfänger ihn genehmigt (nächster Schritt).

  1. Führ den Push auf dem sendenden Server aus. Bei der allerersten Verbindung hält er genau hier an, bis der Empfänger ihn genehmigt.

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

  2. Beantworte die Frage auf dem Empfänger — das ist der nächste Abschnitt. Danach läuft der Push von allein zu Ende, und spätere Pushes halten hier nie wieder an.

  3. Häng einen Port an, wenn der Listener nicht auf 9031 sitzt.

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

So sieht ein erfolgreicher Push aus

Beim ersten Kontakt lernt der Sender den Fingerabdruck des Listeners und heftet ihn an, dann überträgt er. Der Empfänger merkt sich den Fingerabdruck des Pushers und meldet Datei- und Byte-Zahl.

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

Den Sender beim ersten Push genehmigen (auf dem Empfänger)

Wenn eine neue Maschine zum ersten Mal zu deinem Listener pusht, zeigt dir serve (in einem Terminal), woher sie kommt und ihren Fingerprint, und bittet dich, sie zu genehmigen — wie die Erstverbindungs-Abfrage von SSH, nur auf der Empfängerseite:

# auf dem EMPFÄNGER, wenn ein neuer Sender pusht:
Incoming push from 203.0.113.7:54021
  fingerprint: 74318e3b…
Accept and remember this peer? [y/N] y

Automatisieren (oder ohne Terminal betreiben)

Weil ein genehmigter Fingerprint gespeichert bleibt, brauchen spätere Pushes keine Abfrage mehr — relayium push lässt sich also direkt in cron, ein Deploy-Skript oder CI einbinden, für verschlüsselte, integritätsgeprüfte, fortsetzbare Server-zu-Server-Synchronisation. Läuft serve ohne Terminal (ein systemd-Dienst, eine Pipe), kann es nicht nachfragen und lehnt daher unbekannte Pusher ab; genehmige sie stattdessen im Voraus. Hol dir den Fingerprint über relayium id auf der Pusher-Seite, oder kopiere ihn aus der Zeile „rejected unauthorized peer …“ im serve-Log, dann:

# auf dem EMPFÄNGER: einen Sender ohne Abfrage vorab genehmigen
relayium authorize 74318e3b...

Den Listener unter systemd betreiben

Für einen dauerhaft laufenden Posteingang betreibst du serve als systemd-Dienst. Richte --config-dir auf einen festen Ort wie /etc/relayium, damit die Identität über Neustarts hinweg stabil bleibt, und lass systemd sie am Leben halten:

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

Wenn ein Push nicht durchkommt

Erreichbarkeit und Vertrauen sind das Erste, was du prüfst: ss -tinp auf dem Sender zeigt, ob der Listener überhaupt erreicht wurde, und relayium authorize auf dem Empfänger gibt einem abgewiesenen Sender das fehlende Vertrauen. Das sind nicht die einzigen Arten, wie ein Push scheitern kann — ein Empfänger ohne Plattenplatz, ein Eingangsverzeichnis, in das sein Benutzer nicht schreiben darf, oder eine übertragene Datei, die ihre Integritätsprüfung nicht besteht, melden sich alle selbst — lies also den Fehler vor dir, statt anzunehmen, es sei einer der vier unten.

Symptom, Prüfung, Lösung

Der Push steht, dann scheitert er mit einem Verbindungsfehler.
# auf dem SENDER, während der Push läuft — zweimal im Abstand einiger Sekunden
ss -tinp dst :9031
# ESTAB    der Listener wurde erreicht; über Fortschritt sagt das nichts
# SYN-SENT auf dem Port hat nichts geantwortet

SYN-SENT heißt, die Pakete haben nie einen lauschenden Socket erreicht. Prüf auf dem Empfänger mit ss -tlnp | grep 9031, ob serve läuft, und öffne dann 9031/TCP für den Sender in der Host-Firewall und in der Cloud-Sicherheitsgruppe. ESTAB belegt nur die Erreichbarkeit — ein aufgebauter Socket kann untätig oder blockiert sein —, also führ die Prüfung zweimal im Abstand einiger Sekunden aus und vergleich den bytes_acked-Zähler, den -i für diesen Socket ausgibt, um Bewegung von Stillstand zu unterscheiden. Hier gibt es keinen Relay-Weg, ein nicht erreichbarer Listener ist also ein harter Fehlschlag und kein langsamer Lauf.

Im serve-Log steht „rejected unauthorized peer …“ und der Push scheitert.
# auf dem SENDER
relayium id
# 74318e3b…

# auf dem EMPFÄNGER
relayium authorize 74318e3b…

serve hatte kein Terminal zum Nachfragen — eine systemd-Unit oder eine Pipe — also wird ein unbekannter Fingerabdruck abgelehnt statt vertraut. Autorisier ihn vorab: Der Fingerabdruck in der Ablehnungszeile ist genau der, den relayium id auf dem Sender ausgibt, und authorize ist idempotent.

„fingerprint mismatch for receiver.example.com:9031“.
grep receiver.example.com ~/.config/relayium/known_hosts

Der Listener hat einen anderen Schlüssel vorgezeigt als den, der beim ersten Kontakt angeheftet wurde. Hast du den Schlüssel absichtlich rotiert, lösch die passende known_hosts-Zeile und push erneut. Wenn nicht, lass die Zeile stehen und finde heraus, warum sich der Schlüssel geändert hat, bevor du irgendetwas sendest.

Die systemd-Unit stirbt beim Start an einem Fehler über unsichere Dateirechte.
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 lädt keinen privaten Schlüssel, den außer seinem Besitzer noch jemand lesen kann — dieselbe Regel, die ssh anwendet. Führ chmod 600 auf dem Pfad aus, den der Fehler nennt, stell sicher, dass er dem Dienstbenutzer gehört, und starte die Unit neu.

Häufige Fragen

Wie unterscheidet sich daemon-direct von push über SSH?

push über SSH tunnelt die Übertragung durch deine SSH-Verbindung und braucht ein SSH-Konto auf der Gegenseite. daemon-direct braucht weder SSH noch ein Konto — die beiden Server authentifizieren sich gegenseitig per Zertifikats-Fingerprint über TLS mit Pinning, was leichtgewichtiger ist, wenn beide Maschinen dir gehören.

Muss ich Fingerprints von Hand herumkopieren?

Nein. In einem Terminal fordert dich serve auf, jeden neuen Pusher bei seinem ersten Push zu genehmigen — zeigt dabei seine Adresse und seinen Fingerprint — und merkt sich das, sodass spätere Pushes stillschweigend ablaufen. Du greifst nur bei nicht-interaktiven Setups wie einem systemd-Dienst zu relayium id oder relayium authorize, wo niemand da ist, um die Abfrage zu beantworten.

Wo liegen die Identitäts- und Vertrauensdateien?

Standardmäßig in ~/.config/relayium/ (mit --config-dir überschreibbar). id.key / id.crt sind die dauerhafte Identität dieses Hosts, known_hosts enthält die Fingerprints der Listener, zu denen du gepusht hast, und authorized_fingerprints ist die Allow-Liste des Listeners für Pusher.

Was passiert, wenn sich ein Fingerprint ändert?

Der Push wird abgelehnt und warnt. Der Schlüssel des Listeners wird bei der ersten Nutzung in known_hosts gepinnt, sodass eine spätere Änderung — ein neu verschlüsselter Host oder ein Man-in-the-Middle — abgelehnt statt stillschweigend akzeptiert wird. Entferne die known_hosts-Zeile nur, wenn du den Schlüssel absichtlich rotiert hast.

Gibt es einen Relay-Fallback?

Nein. daemon-direct setzt eine erreichbare Listener-Adresse voraus; kann die Verbindung nicht hergestellt werden, schlägt es fehl. Nichts wird jemals über Relayium weitergeleitet — genau das ist der Sinn dieses Modus.

Verbinde zwei deiner eigenen Server für direkte Übertragungen — kein Relay, kein SSH, kein Pairing-Code.

CLI holen

Weiterlesen