چگونه به VPS خود از طریق Tor وصل شویم
Anonymity · 8 دقیقه مطالعه
دو مسئلهٔ متفاوت که هر دو «SSH روی Tor» نامیده میشوند
کسانی که به دنبال دسترسی VPS از طریق Tor میگردند معمولاً در پی حل یکی از دو مسئلهٔ متمایزند و راهاندازی بسته به اینکه کدامیک صدق میکند فرق میکند. اولی سمت کلاینت است: میخواهید آدرس IP خودتان را از سرور، از هرکسی که شبکهٔ محلیتان را زیر نظر دارد و از هرکسی که بعداً برای لاگهای اتصال ارائهدهندهٔ VPS احضاریه میفرستد پنهان کنید. دومی سمت سرور است: میخواهید خود VPS هیچ پورت SSHای قابلدسترس از اینترنت عمومی نداشته باشد، تا نتواند توسط اسکن پورت پیدا شود، هدف یک بات credential-stuffing قرار گیرد یا از روی سرویس در حال گوشدادنش موقعیتیابی شود.
این دو الزاماً منافاتی با هم ندارند. بخش زیادی از سردرگمی در تاپیکهای فرومی دربارهٔ ssh روی tor از این میآید که مردم «میخواهم پنهان کنم چه کسی وصل میشود» را با «میخواهم پنهان کنم به چه چیزی وصل میشود» قاطی میکنند. این راهنما هر دو را پوشش میدهد، ابتدا با راهاندازی سادهٔ سمت کلاینت، سپس رویکرد سرویس onion برای سرور، سپس نحوهٔ سختسازی نتیجه و اینکه واقعاً چه عملکردی باید انتظار داشت.
- ناشناسی سمت کلاینت: کلاینت SSH شما از میان Tor عبور میکند تا سرور (و هرکسی که اتصالات ورودی آن را لاگ میکند) یک خروجی یا رلهٔ Tor ببیند، نه IP واقعی شما
- ناشناسی سمت سرور: sshd فقط از طریق یک آدرس onion در Tor قابلدسترس است، پس اصلاً هیچ IP:پورت عمومیای برای SSH وجود ندارد
روش ۱: مسیردهی کلاینت SSH خود از میان پراکسی SOCKS متعلق به Tor
یک کلاینت در حال اجرای Tor (دیمن Tor، نه لزوماً Tor Browser) یک پراکسی محلی SOCKS5 را نمایان میکند، بهطور پیشفرض روی 127.0.0.1:9050. هر اپلیکیشن SOCKS-aware میتواند به آن اشاره کند، و خودِ SSH بهطور بومی SOCKS صحبت نمیکند، پس به یک پل کوچک نیاز دارید. دو رویکرد رایج torsocks است که یک دستور را میپیچد و اتصالات TCP آن را از میان پراکسی مجبور میکند، و یک ورودی ProxyCommand در پیکربندی SSH شما که اتصال را از میان یک netcat سازگار با SOCKS لولهکشی میکند.
سریعترین آزمایش بهسادگی این است: tor را نصب کنید، مطمئن شوید در حال اجراست، سپس torsocks ssh user@your-vps-ip را اجرا کنید. اگر وصل شد، نشست SSH شما اکنون از میان یک مدار سهگامی Tor عبور میکند. برای چیزی که روزانه استفاده میکنید، بهجای تایپ torsocks در هر بار، یک بلوک Host به ~/.ssh/config اضافه کنید، با استفاده از خطی مانند nc -X 5 -x 127.0.0.1:9050 %h %p (با OpenBSD netcat) یا connect -S 127.0.0.1:9050 %h %p (با ابزار connect-proxy) بهعنوان ProxyCommand. اینطوری، ssh myhost ساده کار میکند و همیشه از میان Tor عبور میکند بدون اینکه لازم باشد ابزار پوششی را به یاد بیاورید.
- پیش از عیبیابی خود SSH، تأیید کنید Tor واقعاً در حال اجرا و در حال گوشدادن روی ۹۰۵۰ است
- 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 میگوید اتصالات واردشده به پورت ۲۲ آدرس 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. چون اتصالات از طریق فرایند محلی Tor به sshd میرسند، آدرس مبدأی که sshd برای هر تلاش ورود، موفق یا ناموفق، لاگ میکند 127.0.0.1 است — هیچ IP مهاجمی برای مسدود کردن نیست. این شکافی نیست که نیاز به یک راهحل جایگزین داشته باشد؛ احراز هویت فقط با کلید و بدون بازگشت به رمز عبور، از قبل ریسک brute-forceای که fail2ban برای کاهش آن ساخته شده را حذف میکند. فقط انتظار نداشته باشید لاگهایش در این پیکربندی معنادار باشند.
- احراز هویت فقط با کلید، ed25519، بدون بازگشت به رمز عبور
- یک جفتکلید اختصاصی برای هر سرور ناشناس، هرگز از دستگاه شخصی استفادهٔ مجدد نشود
- PermitRootLogin no، و یک حساب غیرروت با sudo برای کار واقعی
- بهمحض اینکه ترافیک از طریق Tor میرسد، روی fail2ban یا لیست سفید IP حساب نکنید — IP مبدأ در لاگها همیشه loopback است
عملکرد واقعی چطور به نظر میرسد
یک مدار استاندارد Tor سه رله دارد و یک اتصال سرویس onion دو مدار سهگامی را سر تا سر روی هم میگذارد (یکی از کلاینت به شبکهٔ Tor، یکی از شبکهٔ Tor به سرویس مخفی)، پس تأخیر رفتوبرگشت معمولاً بین چند صد میلیثانیه تا چند ثانیه قرار میگیرد، با گاهی جهشهایی وقتی یک مدار دوباره ساخته میشود. کار تعاملی — ویرایش فایلهای پیکربندی، بررسی لاگها، ریاستارت یک سرویس — کاملاً با آن تأخیر قابلاستفاده است. ServerAliveInterval را در پیکربندی SSH خود تنظیم کنید تا نشستهای بیکار بهخاطر گام اضافه قطع نشوند، و انتظار یک توقف گاهبهگاه هنگام انتخاب مدار جدید توسط Tor را داشته باشید.
چیزی که خوب کار نمیکند توان عملیاتی است. scp، rsync یا هرچیزی که گیگابایتها را جابهجا میکند نسبت به اتصال مستقیم بهکندی میخزد، چون مدارهای Tor برای تعامل با تأخیر پایین در میان جریانهای کوتاهعمر بسیار بهینه شدهاند، نه پهنای باند پایدار. برای انتقال دادهٔ واقعی — پشتیبانگیری، آپلودهای بزرگ — از یک کانال رمزنگاریشدهٔ مستقیم استفاده کنید (SSH/rsync ساده روی IP عمومی، یا یک تونل WireGuard) و مسیر Tor را مشخصاً برای دسترسی مدیریتی پوسته که پنهانماندن اتصال مهمتر از سرعت است، نگه دارید.
اشتباهاتی که بهآرامی ناشناسیای که به دنبالش بودید را نقض میکنند
بیشتر شکستهای اینجا عجیب نیستند — شکافهای پیکربندی کوچکی هستند که یک در فرعی را باز میگذارند. پیش از اینکه به راهاندازی اعتماد کنید، مراقب اینها باشید:
هیچکدام از اینها به ابزار پیشرفتهای برای اجتناب نیاز ندارند؛ فقط نیاز دارند پورتهای واقعاً گوشدهنده و رفتار DNS را یکبار بررسی کنید، بهجای اینکه فرض کنید تنها پیکربندی Tor کار را انجام داده.
- sshd همچنان به رابط عمومی وصل است در کنار سرویس onion، پس پورت «مخفی» هم با یک اسکن پورت ساده پیدا میشود
- حل نام میزبان خارج از Tor (یک جستجوی DNS اتفاقی، یا اپلیکیشنی که پراکسی SOCKS را برای DNS نادیده میگیرد) پیش از شروع خودِ اتصال Tor، فاش میکند به چه میزبانی در حال اتصال هستید
- یک ProxyCommand که بهطور خاموش، اگر Tor در حال اجرا نباشد، به اتصال مستقیم برمیگردد — آن را طوری پیکربندی کنید که در صورت شکست بسته بماند نه باز، تا دیمن Tor مرده یعنی بدون اتصال، نه یک اتصال اتفاقی به شبکهٔ باز
- استفادهٔ مجدد از یک کلید SSH، پرامپت ترمینال یا تاریخچهٔ پوسته که این نشست را به یک هویت غیرناشناس در جای دیگر پیوند میدهد
| روش | چه چیزی را پنهان میکند | تأخیر افزودهشدهٔ معمول | میزان تلاش راهاندازی |
|---|---|---|---|
| SSH مستقیم روی شبکهٔ باز | چیزی فراتر از رمزنگاری خودِ SSH نیست | هیچ | هیچ |
| کلاینت مسیردهیشده از میان پراکسی SOCKS متعلق به Tor | آدرس IP شما، از سرور و لاگهایش | متوسط — تقریباً یک مدار Tor، ~۳۰۰ میلیثانیه تا ۱ ثانیه | کم — torsocks یا یک خط ProxyCommand |
| SSH منتشرشده بهعنوان سرویس onion در Tor | IP عمومی VPS؛ بدون پورت SSH باز روی اینترنت | متوسط تا بالا — مدار سمت سرور اضافه شده | متوسط — تغییرات torrc و sshd_config |
| ترکیب هر دو: کلاینت از طریق Tor، سرور بهعنوان سرویس onion | هر دو سر اتصال کاملاً از شبکهٔ باز دور میمانند | بالاترین — دو مدار مستقل سهگامی | متوسط |
سوالات متداول
آیا SSH روی Tor رمزنگاری SSH را ضعیف میکند؟+
آیا SSH روی Tor برای کار مدیریتی واقعی خیلی کند است؟+
اگر SSH فقط از طریق یک سرویس onion قابلدسترس باشد، آیا هنوز میتوانم از fail2ban استفاده کنم؟+
آیا برای دسترسی به VPS، علاوه بر Tor به یک VPN هم نیاز دارم؟+
آیا هر دو سر باید Tor را اجرا کنند، یا فقط لپتاپ من؟+
آماده رفتن به آفشور هستید؟
بدون KYC، بدون ایمیل — فقط یک کلید ناشناس و رمزارز. راهاندازی در ~55 ثانیه.
VPS خود را پیکربندی کنید →