آخر تحديث: 2026-07-12
حين يكون الجهازان كلاهما لك ويعرف كلٌّ منهما عنوان الآخر، يصبح SSH احتكاكًا زائدًا والتعارف عبئًا محضًا. صُمِّم daemon direct لهذا تمامًا: خادم يُنصِت، والآخر يدفع إليه مباشرةً عبر اتصال TLS 1.3 مُثبَّت. لا مُرحِّل، لا SSH، لا رمز اقتران — الثقة تقوم على المفتاح العام وتُهيَّأ مرةً واحدة.
يغطي هذا الدليل تشغيل المُستمِع، والدفع إليه، واعتماد مُرسِل جديد عند أول اتصال، وأتمتة ذلك، وتشغيل المُستمِع كخدمة systemd.
كل ما يلي هو relayium CLI، فثبّته أولًا إن لم تكن قد فعلت. على macOS وLinux، يُسقط أمر واحد ملفًا ثنائيًا مُسبق البناء في PATH الخاص بك:
curl -fsSL https://relayium.com/install.sh | shعلى الخادم المُستقبِل، يستمع serve للدفعات ويكتبها في مجلد. يعمل باستمرار افتراضيًا؛ أضِف --once لقبول نقلة واحدة ثم الخروج. لا تشارك أي شيء مسبقًا — لا بصمات تنسخها سلفًا:
# على المُستقبِل
relayium serve --dir ~/inbox # أضِف --once لنقلة واحدة؛ و --port لتغيير 9031من الخادم المُرسِل، ادفع إلى عنوان relayium:// الخاص بالمُستقبِل. يُثبِّت الاتصال الأول بصمة المُستقبِل؛ ويتحقق منها كل اتصال بعده، وتُرفَض البصمة المتغيّرة بدل قبولها بصمت — فالمفتاح المُستبدَل أو هجوم الوسيط يُكتشَف، لا يُوثَق به. عند أول دفعة على الإطلاق، ينتظر المُرسِل لحظةً بينما يعتمده المُستقبِل (الخطوة التالية).
# على المُرسِل
relayium push ./build.tar.zst relayium://receiver.example.com
# منفذ غير افتراضي
relayium push ./build.tar.zst relayium://receiver.example.com:9040في أول مرة يدفع فيها جهاز جديد إلى مُستمِعك، يُظهِر لك serve (في طرفية) من أين أتى وبصمته ويطلب منك اعتماده — مثل مُطالبة الاتصال الأول في SSH، لكن على جانب المُستقبِل:
# على المُستقبِل، حين يدفع مُرسِل جديد:
Incoming push from 203.0.113.7:54021
fingerprint: 74318e3b…
Accept and remember this peer? [y/N] yبما أن البصمة المعتمَدة تُحفَظ، لا تحتاج الدفعات اللاحقة إلى مُطالبة — لذا يدخل relayium push مباشرةً في cron أو سكربت نشر أو CI لمزامنة مُشفَّرة، مفحوصة السلامة، قابلة للاستئناف من خادم إلى خادم. حين يعمل serve دون طرفية (خدمة systemd، أنبوب) لا يستطيع المُطالبة، فيرفض المُرسِلين المجهولين؛ فوّض لهم مسبقًا بدلًا من ذلك. احصل على البصمة من relayium id لدى المُرسِل، أو انسخها من سطر «rejected unauthorized peer …» في سجل serve، ثم:
# على المُستقبِل: فوِّض مُرسِلاً مسبقاً دون مُطالبة
relayium authorize 74318e3b...لصندوق وارد دائم التشغيل، شغّل serve كخدمة systemd. وجِّه --config-dir إلى موقع ثابت مثل /etc/relayium كي تبقى الهوية مستقرة عبر إعادات التشغيل، ودع systemd يُبقيها حيّة:
# /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يوجِّه push عبر SSH النقل خلال اتصال SSH لديك ويحتاج إلى حساب SSH على الطرف البعيد. أما daemon direct فلا يحتاج SSH ولا حسابًا — يصادق الخادمان أحدهما الآخر ببصمة الشهادة عبر TLS مُثبَّت، وهو أخف حين يكون الجهازان كلاهما لك.
لا. في طرفية، يطالبك serve باعتماد كل مُرسِل جديد عند أول دفعة له — مُظهِرًا عنوانه وبصمته — ويحفظه، فتمر الدفعات اللاحقة بصمت. لا تلجأ إلى relayium id أو relayium authorize إلا في الإعدادات غير التفاعلية مثل خدمة systemd، حيث لا أحد ليُجيب على المُطالبة.
في ~/.config/relayium/ افتراضيًا (تُتجاوَز بـ --config-dir). id.key / id.crt هما الهوية الدائمة لهذا المضيف، ويحتفظ known_hosts ببصمات المُستمِعين الذين دفعت إليهم، أما authorized_fingerprints فهو قائمة السماح بالمُرسِلين لدى المُستمِع.
تُرفَض الدفعة ويُطلَق تحذير. يُثبَّت مفتاح المُستمِع في known_hosts عند أول استخدام، فأي تغيّر لاحق — مضيف أُعيد ترميزه، أو هجوم وسيط — يُرفَض بدل قبوله بصمت. لا تحذف سطر known_hosts إلا إن كنت قد بدّلت المفتاح عمدًا.
لا. يفترض daemon direct عنوان مُستمِع يمكن الوصول إليه؛ فإن تعذَّر إنشاء الاتصال، يفشل. لا يُوجَّه أي شيء أبدًا عبر Relayium — وهذا هو مغزى هذا الوضع.
اربط خادمين من خوادمك للنقل المباشر — دون مُرحِّل، دون SSH، دون رمز اقتران.
احصل على CLI