كيفية الاتصال بخادم VPS الخاص بك عبر Tor

Anonymity · 8 دقائق قراءة

إجابة سريعة: يمكنك توجيه SSH عبر Tor باتجاهين: توجيه عميلك إلى وكيل SOCKS المحلي لـ Tor لإخفاء عنوان IP الخاص بك عن الخادم، أو نشر منفذ SSH الخاص بالـ VPS كخدمة onion على Tor بحيث لا يكون لدى الخادم نفسه منفذ SSH يمكن الوصول إليه على الشبكة المفتوحة على الإطلاق. يمكن الجمع بين الطريقتين بحيث لا يلمس أي طرف من الجلسة الإنترنت المفتوح مطلقًا. توقّع زمن استجابة أعلى بشكل ملموس مقارنة باتصال مباشر، لذا عاملها كتقنية للوصول الإداري في العمل التفاعلي عبر الطرفية، لا كوسيلة نقل لملفات كبيرة.

مشكلتان مختلفتان، تُسمّيان كلتاهما 'SSH عبر Tor'

الأشخاص الذين يبحثون عن الوصول إلى VPS عبر Tor يحاولون عادةً حل واحدة من مشكلتين متمايزتين، ويختلف الإعداد حسب المشكلة المعنية. الأولى من جانب العميل: تريد إخفاء عنوان IP الخاص بك عن الخادم، وعن أي شخص يراقب شبكتك المحلية، وعن أي جهة تستدعي لاحقًا سجلات اتصال مزود الـ VPS. الثانية من جانب الخادم: تريد ألا يكون لدى الـ VPS نفسه منفذ SSH يمكن الوصول إليه من الإنترنت العام على الإطلاق، بحيث لا يمكن العثور عليه بواسطة ماسح منافذ، أو استهدافه بواسطة بوت لحشو بيانات الاعتماد، أو تحديد موقعه الجغرافي عبر خدمته المُصغية.

هاتان المشكلتان ليستا متنافيتين. الكثير من الالتباس في مواضيع المنتديات حول SSH عبر Tor ينشأ من خلط الناس بين 'أريد إخفاء من يتصل' و'أريد إخفاء ما الذي يُتَّصل به'. يغطي هذا الدليل كليهما، بدءًا من الإعداد الأبسط من جانب العميل، ثم نهج خدمة onion للخادم، ثم كيفية تعزيز النتيجة، وأي أداء يُتوقع فعليًا.

إخفاء الهوية من جانب العميل: يوجَّه عميل SSH الخاص بك عبر Tor بحيث يرى الخادم (وأي جهة تسجّل اتصالاته الواردة) عقدة خروج أو مُرحّل Tor، لا عنوان IP الحقيقي الخاص بك
إخفاء الهوية من جانب الخادم: لا يمكن الوصول إلى sshd إلا عبر عنوان onion على Tor، بحيث لا يوجد عنوان IP:منفذ عام لـ SSH على الإطلاق

الطريقة الأولى: توجيه عميل SSH عبر وكيل SOCKS الخاص بـ Tor

يعرض عميل Tor العامل (خدمة Tor نفسها، وليس بالضرورة متصفح Tor) وكيل SOCKS5 محليًا، افتراضيًا على 127.0.0.1:9050. يمكن توجيه أي تطبيق يدعم SOCKS إليه، ولا يتحدث SSH نفسه لغة SOCKS أصلًا، لذا تحتاج جسرًا صغيرًا. النهجان الشائعان هما torsocks، الذي يغلّف أمرًا ويجبر اتصالاته عبر بروتوكول TCP على المرور عبر الوكيل، وإدخال ProxyCommand في إعدادات SSH الخاصة بك يمرر الاتصال عبر أداة netcat تدعم SOCKS.

أسرع اختبار هو ببساطة: ثبّت Tor، وتأكد من أنه يعمل، ثم شغّل torsocks ssh user@your-vps-ip. إذا نجح الاتصال، فإن جلسة SSH الخاصة بك الآن موجَّهة عبر دائرة Tor ثلاثية القفزات. لشيء ستستخدمه يوميًا، أضف كتلة Host إلى ~/.ssh/config بدلًا من كتابة torsocks في كل مرة، باستخدام سطر ProxyCommand مثل nc -X 5 -x 127.0.0.1:9050 %h %p (مع OpenBSD netcat) أو connect -S 127.0.0.1:9050 %h %p (مع أداة connect-proxy). بهذه الطريقة يعمل ssh myhost العادي ويمر دائمًا عبر Tor دون أن تضطر لتذكّر الغلاف.

تحقق من أن Tor يعمل فعليًا ويستمع على المنفذ 9050 قبل استكشاف مشاكل SSH نفسه
torsocks ssh user@host هي أسرع طريقة للاختبار؛ وإدخال ProxyCommand في ~/.ssh/config هو الطريقة الدائمة للاستخدام اليومي
تُخفي هذه الطريقة عنوان IP الخاص بك عن الـ VPS وعن أي جهة تقرأ سجلات مصادقته، لكن منفذ SSH نفسه يبقى مفتوحًا للإنترنت العام

الطريقة الثانية: نشر SSH كخدمة onion على Tor في الـ VPS

إذا كان الهدف هو إبعاد عنوان IP الخاص بالـ VPS نفسه تمامًا عن الصورة للوصول الإداري، فيحتاج الخادم إلى تشغيل Tor وكشف sshd فقط كخدمة مخفية. ثبّت Tor على الـ VPS، ثم أضف سطرين إلى torrc: HiddenServiceDir يشير إلى دليل يمكن لـ Tor الكتابة فيه، و HiddenServicePort 22 127.0.0.1:22، الذي يخبر Tor بإعادة توجيه الاتصالات الواردة إلى المنفذ 22 من عنوان onion إلى خدمة sshd المُصغية محليًا. أعد تشغيل Tor، وسيولّد اسم مضيف onion عشوائي طويل في ذلك الدليل عند أول تشغيل.

الأهم من ذلك، هذه الخطوة تزيل التعرض فقط إذا طُلب من sshd أيضًا الارتباط بـ 127.0.0.1 بدلًا من الواجهة العامة للـ VPS (ListenAddress 127.0.0.1 في sshd_config، ثم إعادة تشغيل sshd). تخطي هذه الخطوة يترك SSH قابلًا للوصول عبر عنوان onion وعلى الـ IP العام مباشرة في آن واحد، مما يُبطل الغرض. بمجرد الانتهاء من ذلك، اتصل من جانب العميل باستخدام torsocks ssh [email protected] — لن يظهر أي عنوان IPv4 أو IPv6 عام لـ SSH أبدًا في مسح منافذ للـ VPS.

أضف HiddenServiceDir و HiddenServicePort 22 127.0.0.1:22 إلى torrc، ثم أعد تشغيل Tor
اربط sshd نفسه بـ 127.0.0.1 فقط — خدمة onion أمام منفذ لا يزال عامًا لا تخفي شيئًا
اقرأ ملف اسم المضيف المُولَّد داخل HiddenServiceDir للحصول على عنوان onion الذي ستتصل به
اتصل باستخدام torsocks ssh [email protected]؛ لن يعمل عنوان IP مجرد لـ SSH على الإطلاق بعد الآن

تأمين المصادقة بمجرد أن يستجيب SSH فقط على .onion

إخفاء المنفذ لا يغني عن تعزيز تسجيل الدخول. استخدم أزواج مفاتيح ed25519، وعطّل المصادقة بكلمة المرور تمامًا (PasswordAuthentication no)، وعطّل تسجيل دخول الجذر عبر SSH (PermitRootLogin no). إذا كان المفتاح الذي تستخدمه للوصول إلى هذا الـ VPS هو نفسه الذي تستخدمه لحساباتك اليومية، فإن إخفاء الهوية الذي اكتسبته خدمة onion يُقوَّض في اللحظة التي يظهر فيها بصمة ذلك المفتاح في تسريب اختراق أو مسح Shodan/Censys مرتبط باسمك في مكان آخر — ولّد مفتاحًا مخصصًا للبنية التحتية المجهولة.

هناك أمر واحد يتوقف عن العمل بهدوء في هذا الإعداد: الأدوات القائمة على IP مثل fail2ban. نظرًا لأن الاتصالات تصل إلى sshd عبر عملية Tor المحلية، يكون عنوان المصدر الذي يسجّله sshd هو 127.0.0.1 لكل محاولة تسجيل دخول، ناجحة كانت أم لا — لا يوجد IP مهاجم لحظره. ليست هذه ثغرة تحتاج إلى سدّها بحل بديل؛ المصادقة بالمفاتيح فقط دون بديل بكلمة مرور تزيل بالفعل خطر القوة الغاشمة الذي وُجد fail2ban للتخفيف منه. فقط لا تتوقع أن تكون سجلاته ذات معنى في هذا الإعداد.

مصادقة بالمفاتيح فقط، ed25519، بلا بديل بكلمة مرور
زوج مفاتيح مخصص لكل خادم مجهول، لا يُعاد استخدامه أبدًا من جهاز شخصي
PermitRootLogin no، وحساب غير جذر مع صلاحيات sudo للعمل الفعلي
لا تعتمد على fail2ban أو قوائم السماح القائمة على IP بمجرد وصول الحركة عبر Tor — عنوان IP المصدر في السجلات هو دائمًا loopback

كيف يبدو الأداء فعليًا

دائرة Tor القياسية تتكون من ثلاثة مُرحّلات، ويكدّس اتصال خدمة onion دائرتين ثلاثيتي القفزات من طرف إلى طرف (واحدة من العميل إلى شبكة Tor، وأخرى من شبكة Tor إلى الخدمة المخفية)، لذا يقع زمن الاستجابة ذهابًا وإيابًا عادةً بين بضع مئات من المللي ثانية وثانيتين، مع ارتفاعات عرضية عند إعادة بناء دائرة. العمل التفاعلي — تحرير ملفات الإعداد، فحص السجلات، إعادة تشغيل خدمة — قابل للاستخدام تمامًا عند زمن الاستجابة هذا. اضبط ServerAliveInterval في إعدادات SSH الخاصة بك حتى لا تُفصل الجلسات الخاملة بسبب القفزة الإضافية، وتوقّع توقفًا عرضيًا بينما يختار Tor دائرة جديدة.

ما لا يعمل بشكل جيد هو الإنتاجية (throughput). ستزحف عمليات scp أو rsync أو أي شيء ينقل غيغابايتات مقارنةً باتصال مباشر، لأن دوائر Tor مُحسَّنة للتفاعلية منخفضة زمن الاستجابة عبر تدفقات قصيرة العمر عديدة، لا للنطاق الترددي المستدام. لنقل البيانات الفعلي — النسخ الاحتياطي، الرفع الكبير — استخدم قناة مشفرة مباشرة (SSH/rsync عادي عبر الـ IP العام، أو نفق WireGuard) واحتفظ بمسار Tor خصيصًا للوصول الإداري إلى الطرفية حيث يهم إخفاء الاتصال أكثر من السرعة.

أخطاء تكسر بهدوء إخفاء الهوية الذي كنت تحاول تحقيقه

معظم الإخفاقات هنا ليست غريبة — إنها ثغرات إعداد صغيرة تترك بابًا جانبيًا مفتوحًا. راقب هذه الأمور قبل أن تثق بالإعداد:

لا يتطلب أي من هذه أدوات متقدمة لتجنبه؛ إنها تتطلب فقط التحقق من المنافذ المُصغية الفعلية وسلوك DNS مرة واحدة، بدلًا من افتراض أن إعداد Tor وحده قد أنجز المهمة.

لا يزال sshd مرتبطًا بالواجهة العامة إلى جانب خدمة onion، لذا فإن المنفذ 'المخفي' يمكن العثور عليه أيضًا بمسح منافذ عادي
حلّ أسماء المضيفين خارج Tor (بحث DNS شارد، أو تطبيق يتجاهل وكيل SOCKS لـ DNS) يسرّب المضيف الذي توشك على الاتصال به قبل أن يبدأ اتصال Tor أصلًا
ProxyCommand يعود بصمت إلى اتصال مباشر إذا لم يكن Tor يعمل — اضبطه ليفشل مغلقًا، لا مفتوحًا، بحيث يعني موت خدمة Tor عدم وجود اتصال بدلًا من اتصال عرضي على الشبكة المفتوحة
إعادة استخدام مفتاح SSH، أو موجّه طرفية، أو سجل أوامر يربط هذه الجلسة بهوية غير مجهولة في مكان آخر

مقارنة طرق الوصول عبر SSH
الطريقة	ما تخفيه	زمن الاستجابة الإضافي النموذجي	جهد الإعداد
SSH مباشر عبر الشبكة المفتوحة	لا شيء يتجاوز تشفير SSH نفسه	لا شيء	لا شيء
عميل موجَّه عبر وكيل SOCKS الخاص بـ Tor	عنوان IP الخاص بك، من الخادم وسجلاته	متوسط — دائرة Tor واحدة تقريبًا، ~300 مللي ثانية إلى ثانية	منخفض — torsocks أو سطر ProxyCommand
SSH منشور كخدمة onion على Tor	عنوان IP العام للـ VPS؛ لا منفذ SSH مفتوح على الإنترنت	متوسط إلى مرتفع — دائرة إضافية من جانب الخادم	متوسط — تغييرات على torrc و sshd_config
الجمع بين الاثنين: عميل عبر Tor، خادم كخدمة onion	يبقى طرفا الاتصال بعيدين عن الشبكة المفتوحة تمامًا	الأعلى — دائرتان مستقلتان ثلاثيتا القفزات	متوسط

الأسئلة الشائعة

هل يُضعف SSH عبر Tor تشفير SSH؟+

لا. يتفاوض SSH على قناته المشفرة من طرف إلى طرف بشكل مستقل عن وسيلة النقل التي تحمله. يضيف Tor طبقة تشفير الدائرة الخاصة به فوق ذلك، لذا تُشفَّر الحركة مرتين، لا مرة واحدة بشيء أضعف.

هل SSH عبر Tor بطيء جدًا لعمل إداري حقيقي؟+

بالنسبة لجلسات الطرفية التفاعلية — تحرير الملفات، فحص السجلات، إعادة تشغيل الخدمات — زمن الاستجابة الإضافي ملحوظ لكنه مُدار. أما لعمليات النقل الكبيرة مثل النسخ الاحتياطي أو الرفع الكبير، فاستخدم اتصالًا مباشرًا أو WireGuard بدلًا من ذلك واحتفظ بمسار Tor للوصول الإداري.

هل يمكنني استخدام fail2ban إذا كان SSH متاحًا فقط عبر خدمة onion؟+

ليس بمعنى مفيد. تصل الاتصالات إلى sshd من عملية Tor المحلية، لذا تُسجَّل كل محاولة تسجيل دخول كأنها قادمة من 127.0.0.1. اعتمد بدلًا من ذلك على المصادقة بالمفاتيح فقط دون بديل بكلمة مرور، لأن ذلك يزيل خطر القوة الغاشمة الذي صُمم fail2ban لمعالجته.

هل أحتاج إلى VPN إضافة إلى Tor للوصول إلى VPS؟+

ليس عادةً. تسلسل VPN تجاري أمام Tor ينقل الثقة إلى مزود VPN غالبًا دون إضافة حماية حقيقية لهذه الحالة. يغطي Tor وحده لجلسة SSH، أو نفق WireGuard عندما يكون زمن الاستجابة أهم من التوجيه عبر شبكة Tor، الحالات العملية.

هل يحتاج كلا الطرفين لتشغيل Tor، أم جهاز الكمبيوتر المحمول فقط؟+

يحتاج عميلك فقط إلى تشغيل Tor لإخفاء عنوان IP الخاص بك عن الخادم (الطريقة الأولى). إخفاء عنوان IP الخاص بالخادم أيضًا يتطلب أن يشغّل الـ VPS خدمة Tor أيضًا، مع نشر sshd كخدمة onion (الطريقة الثانية) — الإعدادان مستقلان ويمكن استخدامهما منفصلَين أو معًا.

جاهز للانتقال إلى الاستضافة الخارجية؟

بدون KYC، وبدون بريد إلكتروني — فقط مفتاح مجهول وعملات رقمية. النشر خلال ~55 ثانية.

تهيئة خادم VPS الخاص بك →