اتصال SSH از طریق Tor Onion بدون باز کردن پورت

تغییرات استفاده از SSH روی سرویس onion شبکه Tor

استفاده از SSH روی یک سرویس onion در شبکه Tor به شما امکان می‌دهد سرور مجازی (VPS) را مدیریت کنید که هیچ اتصال ورودی را روی هیچ پورتی نمی‌پذیرد. سرور به شبکه Tor متصل می‌شود و آن اتصال را باز نگه می‌دارد. نشست SSH شما از طریق همین مسیر بازمی‌گردد، بنابراین نیازی نیست هیچ سرویسی روی IP عمومی گوش دهد.

تأثیر این کار روی لاگ‌ها بلافاصله قابل مشاهده است. سروری که پورت SSH عمومی دارد، روزانه هزاران تلاش ناموفق برای ورود توسط اسکنرها دریافت می‌کند. اگر sshd را پشت یک سرویس onion ببرید و ترافیک ورودی را در فایروال مسدود کنید، /var/log/auth.log تنها نشست‌هایی را ثبت می‌کند که خودتان آغاز کرده‌اید.

هزینه این کار این است که tor در مسیر تمام نشست‌های مدیریتی قرار می‌گیرد. این یک daemon در فضای کاربری (userspace) است که باید پس از هر بار reboot اجرا و راه‌اندازی شود تا بتوانید وارد شوید. پیش از بستن پورت، برای این موضوع برنامه‌ریزی کنید؛ چرا که حالت شکست در اینجا، از دست دادن دسترسی به ماشینی است که از نظر فیزیکی به آن دسترسی ندارید.

پیش از هر تغییری، راه دسترسی جایگزین ایجاد کنید

تا زمانی که یک مسیر بازیابی (recovery path) بدون استفاده از SSH ندارید، کار را شروع نکنید.

هم‌اکنون کنسول ارائه‌دهندهٔ خود (VNC یا کنسول سریال در پنل مدیریت) را باز کرده و با آن وارد شوید. اگر رمز عبور root را نمی‌دانید، ابتدا رمز عبور root را از طریق پنل بازنشانی کنید و از صحت عملکرد آن مطمئن شوید. کنسولی که هرگز آن را تست نکرده‌اید، مسیر بازیابی محسوب نمی‌شود.

ترتیب مراحل زیر اهمیت دارد. هر گام پیش از اجرای گام بعدی تست شده است و پورت 22 تا زمانی که مسیر onion کار نکند، باز می‌ماند.

1. tor را نصب کرده و از bootstrap شدن آن اطمینان حاصل کنید.
2. سرویس onion را تعریف کرده و آدرس آن را بخوانید.
3. در حالی که پورت 22 هنوز باز است، از طریق onion متصل شوید.
4. احراز هویت کلاینت (client authorisation) را اضافه کرده و دوباره متصل شوید.
5. سرویس sshd را به loopback محدود کرده و پورت 22 را ببندید.
6. سیستم را reboot کرده و دوباره از طریق onion متصل شوید.

نشست (session) فعلی SSH خود را در تمام طول مراحل باز نگه دارید. یک نشست برقرار، در برابر تغییرات فایروال که مانع از ایجاد نشست جدید می‌شوند مقاوم است؛ بنابراین این نشست، خط اول دفاعی شما برای بازیابی است.

نصب tor روی سرور

توزیع Ubuntu نرم‌افزار tor را در مخازن خود ارائه می‌دهد، اما نسخهٔ موجود در آن معمولاً قدیمی است. مخزن رسمی The Tor Project شامل نسخه‌ای است که در مستندات آن‌ها توصیف شده است. آن را با استفاده از دستورات موجود در راهنمای مخزن apt اضافه کنید.

sudo apt update
sudo apt install -y apt-transport-https wget gpg
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

دستور /etc/apt/sources.list.d/tor.sources را بنویسید. Suites نام رمز (codename) توزیع شما را دریافت می‌کند که lsb_release -cs آن را چاپ می‌کند (noble در Ubuntu 24.04).

Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: noble
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg

sudo apt update
sudo apt install -y tor deb.torproject.org-keyring
sudo journalctl -u tor@default -n 20 --no-pager

لاگ باید با Bootstrapped 100% (done) پایان یابد. توقف در وضعیت پایین‌تر از آن به این معناست که tor نمی‌تواند به شبکه متصل شود، که تقریباً همیشه به دلیل قوانین فایروال خروجی یا تنظیم نبودن ساعت سیستم است.

نام unit یک تله است. دستور systemctl status tor حتی زمانی که همه چیز سالم است، Active: active (exited) را گزارش می‌دهد، زیرا بسته‌های tor در Debian و Ubuntu به عنوان یک master unit چند نمونه‌ای (multi-instance) تعریف شده‌اند که تنها وظیفه‌اش فراخوانی نمونهٔ اصلی است. خود daemon با نام tor@default.service اجرا می‌شود. از این نام برای status و journalctl استفاده کنید. دستورات start، stop و reload برای tor همچنان روی نمونهٔ اصلی اثر می‌گذارند، بنابراین sudo systemctl reload tor همان‌طور که انتظار دارید کار می‌کند.

تعریف سرویس onion برای پورت 22

دو خط زیر را به /etc/tor/torrc اضافه کنید.

HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 22 127.0.0.1:22

خط دوم به tor دستور می‌دهد که پورت مجازی 22 را روی آدرس onion بپذیرد و به 127.0.0.1:22 روی همین سیستم متصل شود. Tor از طریق loopback به sshd دسترسی پیدا می‌کند؛ دقیقاً به همین دلیل است که sshd می‌تواند پس از آن، گوش دادن روی آدرس عمومی را متوقف کند. اگر آن خط دوم را به جای آن به یک وب‌سرور روی 127.0.0.1:80 اشاره دهید، همان دو دستور انتشار یک سایت روی آدرس onion را انجام می‌دهند که سرویس دوم مفیدی برای اجرا پس از نصب tor است.

sudo systemctl reload tor
sudo cat /var/lib/tor/ssh/hostname

این دستور 56 کاراکتر base32 را به همراه .onion چاپ می‌کند. این کاراکترها همان کلید عمومی سرویس به صورت کدگذاری‌شده هستند. در این فرآیند هیچ مرجع صدور گواهی (CA) یا ثبت نامی وجود ندارد.

اجازه دهید tor خودش /var/lib/tor/ssh/ را ایجاد کند. اگر آن را به صورت دستی با مالک اشتباه یا دسترسی‌های بازتر از 0700 بسازید، tor از استفاده از آن خودداری می‌کند و در journal گزارش می‌دهد که دایرکتوری بیش از حد در دسترس است. فایل‌های داخل آن، هویت سرویس هستند: hs_ed25519_secret_key همان آدرس است. از این دایرکتوری با مجوز 600 نسخه پشتیبان تهیه کنید و کپی آن را خارج از سرور نگه دارید، زیرا از دست دادن آن به معنای تغییر آدرس و نیاز به ویرایش پیکربندی در تمام کلاینت‌ها خواهد بود.

اتصال از ایستگاه کاری

ایستگاه کاری شما به یک کلاینت Tor نیاز دارد که هیچ نیازی به پیکربندی ندارد. در Debian یا Ubuntu این کار با sudo apt install -y tor netcat-openbsd انجام می‌شود. سپس Tor روی 127.0.0.1:9050 به عنوان یک SOCKS5 proxy گوش می‌دهد. SOCKS یک پروتکل پروکسی عمومی است و نسخه 5 آن می‌تواند به جای آدرس IP، نام میزبان (hostname) را منتقل کند که در اینجا بخش مهم ماجراست.

OpenSSH کلاینت SOCKS داخلی ندارد، بنابراین یک برنامه کمکی اتصال را برقرار می‌کند. این تنظیمات را به ~/.ssh/config اضافه کنید.

Host myvps
  HostName xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion
  User admin
  ProxyCommand /usr/bin/nc -X 5 -x 127.0.0.1:9050 %h %p
  ServerAliveInterval 30

-X 5 پروتکل SOCKS5 را انتخاب می‌کند و -x 127.0.0.1:9050 به Tor محلی اشاره دارد. %h نام onion را به عنوان یک نام به Tor تحویل می‌دهد تا Tor آن را درون شبکه ترجمه (resolve) کند. این برنامه باید OpenBSD netcat باشد. نسخه GNU netcat فاقد گزینه -X است و با خطای nc: invalid option -- 'X' متوقف می‌شود.

ssh myvps

اتصال اول کند است، زیرا Tor پیش از هر اتفاق دیگری یک مدار (circuit) ایجاد می‌کند. اثر انگشت (fingerprint) کلید میزبان را همان‌طور که در هر جای دیگری تأیید می‌کنید، بپذیرید. از اینجا به بعد مدیریت معمول کلیدهای SSH بدون تغییر اعمال می‌شود. لایه انتقال تغییر کرده است، اما احراز هویت خیر.

برای یک اتصال موردی، می‌توانید از وارد کردن تنظیمات صرف‌نظر کنید: دستور torsocks ssh admin@xxxxx.onion همان کار را انجام می‌دهد.

افزودن احراز هویت کلاینت v3

در وضعیت فعلی، هر کسی که آدرس را به دست آورد می‌تواند به بنر SSH شما متصل شود و شروع به حدس زدن رمز عبور کند. آدرس‌های Onion از طریق سیستم دایرکتوری قابل شمارش نیستند، بنابراین آدرس مانند یک راز عمل می‌کند، اما از روش‌های معمولی نشت می‌کند: تاریخچه شل (shell history) و فایل‌های پیکربندی که در مخزن git ثبت شده‌اند. احراز هویت کلاینت این شکاف را می‌بندد. سرویس، توصیف‌گر (descriptor) خود را به‌صورت رمزنگاری‌شده با کلید کلاینت منتشر می‌کند، بنابراین کسی که آدرس را دارد اما کلید ندارد، حتی نمی‌تواند موقعیت سرویس را پیدا کند.

یک جفت کلید x25519 روی کلاینت تولید کنید. این خط لوله (pipeline) از راهنمای احراز هویت کلاینت پروژه Tor است، با یک تغییر کوچک.

openssl genpkey -algorithm x25519 -out /tmp/k1.prv.pem
grep -v " PRIVATE KEY" /tmp/k1.prv.pem | base64 -d | tail --bytes=32 | base32 | sed 's/=//g' > /tmp/k1.prv.key
openssl pkey -in /tmp/k1.prv.pem -pubout | grep -v " PUBLIC KEY" | base64 -d | tail --bytes=32 | base32 | sed 's/=//g' > /tmp/k1.pub.key

نسخه منتشر شده آن خطوط از base64pem -d استفاده می‌کند که در نصب پیش‌فرض Ubuntu وجود ندارد. در نتیجه دستور با خطای base64pem: command not found متوقف می‌شود. ابزار GNU base64 -d همان بدنه PEM را رمزگشایی می‌کند، بنابراین از آن استفاده کنید.

روی سرور، کلید عمومی را نصب کنید.

sudo install -d -m 700 -o debian-tor -g debian-tor /var/lib/tor/ssh/authorized_clients
echo "descriptor:x25519:PASTE_PUBLIC_KEY_HERE" | sudo tee /var/lib/tor/ssh/authorized_clients/laptop.auth >/dev/null
sudo chown debian-tor:debian-tor /var/lib/tor/ssh/authorized_clients/laptop.auth
sudo systemctl reload tor

فقط فایل‌هایی که با .auth ختم می‌شوند خوانده می‌شوند. اگر آن را با نام laptop.auth.txt ذخیره کنید، tor فایل را نادیده می‌گیرد بدون اینکه خطایی چاپ کند و سرویس همچنان برای هر کسی که آدرس را داشته باشد باز می‌ماند.

روی کلاینت، کلید خصوصی را نصب کنید. در Ubuntu، دیمون tor با کاربر debian-tor اجرا می‌شود و نمی‌تواند فایل‌های موجود در دایرکتوری خانگی شما را بخواند، بنابراین دایرکتوری را در جایی قرار دهید که آن کاربر به آن دسترسی داشته باشد.

sudo install -d -m 700 -o debian-tor -g debian-tor /var/lib/tor/onion_auth
echo "ADDRESS_WITHOUT_DOT_ONION:descriptor:x25519:PASTE_PRIVATE_KEY_HERE" | sudo tee /var/lib/tor/onion_auth/myvps.auth_private >/dev/null
sudo chown debian-tor:debian-tor /var/lib/tor/onion_auth/myvps.auth_private
sudo chmod 600 /var/lib/tor/onion_auth/myvps.auth_private

عبارت ClientOnionAuthDir /var/lib/tor/onion_auth را به فایل /etc/tor/torrc کلاینت اضافه کنید و tor را reload کنید. اگر tor را با کاربر خودتان اجرا می‌کنید (مثلاً در نسخه Homebrew روی macOS)، مسیر ClientOnionAuthDir را با حالت 0700 به ~/.tor/onion_auth اشاره دهید.

آدرس داخل آن فایل، همان 56 کاراکتر بدون پسوند .onion است. پس از اتمام کار، /tmp/k1.prv.pem و /tmp/k1.prv.key را حذف کنید.

اکنون هر دو جهت را تست کنید. ssh myvps باید همچنان متصل شود. از ماشینی که کلید ندارد، همان آدرس باید با شکست مواجه شود. آن شکست، گواه شما بر فعال بودن احراز هویت است.

بستن پورت 22، به این ترتیب

ابتدا یک شبکه ایمنی ایجاد کنید. این دستور در صورتی که دسترسی خود را از دست بدهید، هر دو تغییر زیر را پس از 15 دقیقه لغو می‌کند.

sudo systemd-run --on-active=15m --unit=ssh-rescue \
  /bin/sh -c 'ufw allow 22/tcp; rm -f /etc/systemd/system/ssh.socket.d/override.conf; systemctl daemon-reload; systemctl restart ssh.socket'

پس از اطمینان از اینکه مسیر onion همچنان کار می‌کند، با دستور sudo systemctl stop ssh-rescue.timer آن را لغو کنید.

سپس، گوش دادن sshd روی آدرس عمومی را متوقف کنید. در Ubuntu 24.04، سرویس ssh از طریق یک socket unit فعال می‌شود، بنابراین ListenAddress در sshd_config نادیده گرفته می‌شود: ssh.socket مالک سوکت شنونده است، نه sshd. بررسی کنید در کدام وضعیت قرار دارید.

systemctl is-enabled ssh.socket

اگر خروجی دستور enabled بود، sudo systemctl edit ssh.socket را اجرا کرده و این مورد را اضافه کنید.

[Socket]
ListenStream=
ListenStream=127.0.0.1:22

مقدار خالی ListenStream=، مقداری که از unit بسته‌بندی‌شده به ارث رسیده است را پاک می‌کند. اگر این خط را حذف کنید، یک شنونده دوم اضافه می‌شود در حالی که شنونده عمومی همچنان فعال می‌ماند؛ این رایج‌ترین دلیلی است که این مرحله بدون اعلام خطا، با شکست مواجه می‌شود.

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
ss -tlnp | grep ':22'

ss باید 127.0.0.1:22 را نشان دهد و هیچ چیزی روی 0.0.0.0:22 نباشد. اگر ssh.socket غیرفعال بود، ListenAddress 127.0.0.1 را در /etc/ssh/sshd_config.d/10-onion.conf قرار دهید، sudo systemctl restart ssh را اجرا کنید و سپس با همان خط ss بررسی کنید. آن خروجی در هر دو حالت، سند نهایی است.

سپس فایروال را تنظیم کنید که یک مدیریت قوانین ufw روی VPS معمولی است. ابتدا sudo ufw status numbered را اجرا کنید و هر قانونی که مربوط به SSH است را حذف کنید.

sudo ufw status numbered
sudo ufw delete allow OpenSSH
sudo ufw default allow outgoing
sudo ufw default deny incoming
sudo ufw status verbose

ترافیک خروجی را مجاز بگذارید. Tor به رله‌ها روی پورت‌هایی مانند 443 و 9001 متصل می‌شود، بنابراین یک سیاست پیش‌فرض deny برای ترافیک خروجی، باعث توقف bootstrapping در Tor شده و در همان لحظه تنها راه دسترسی باقی‌مانده شما را نیز مسدود می‌کند. اکثر ارائه‌دهندگان خدمات، یک فایروال شبکه جداگانه در پنل کنترل خود دارند. پورت 22 را در آنجا نیز ببندید، در غیر این صورت پورت بدون توجه به گزارش‌های ufw، همچنان در دسترس باقی می‌ماند.

اگر Docker روی این سرور اجرا می‌شود، پیش از پایان کار، پورت‌های منتشرشده آن را بررسی کنید. Docker قوانین خود را مستقیماً در همان جداول می‌نویسد و پورت‌های کانتینر را بدون توجه به ufw منتشر می‌کند، بنابراین یک سیاست deny در ufw تصویر کاملی از وضعیت امنیت ارائه نمی‌دهد.

پیش از اعتماد به سرویس، آن را Reboot کنید

systemctl is-enabled tor@default
sudo reboot

اگر دستور اول وضعیت سرویس را به عنوان enabled گزارش نمی‌کند، پیش از reboot کردن، دستور sudo systemctl enable tor@default را اجرا کنید. 2 دقیقه صبر کنید و سپس ssh myvps را انجام دهید. سرویس Tor پس از بالا آمدن سیستم نیاز به bootstrap شدن دارد، بنابراین onion address مدتی پس از روشن شدن ماشین پاسخ‌دهی را آغاز می‌کند.

اگر سرویس بالا نیامد، کنسول را باز کرده و sudo journalctl -u tor@default -b را مطالعه کنید. خطاهای نحوی در torrc یا مشکلات مربوط به مجوز دسترسی به دایرکتوری‌ها در آنجا ثبت می‌شود. همچنین می‌توانید پیش از اعمال تغییرات در فایل torrc، صحت آن را بررسی کنید.

sudo -u debian-tor tor --verify-config

هزینه‌های این روش در مقایسه با تونل WireGuard

در مقایسه با یک VPN مبتنی بر WireGuard روی VPS شخصی، سرویس onion کندتر است و پیش‌بینی‌پذیری کمتری دارد. پیش از تصمیم‌گیری نهایی، با خود درباره این تفاوت‌ها صادق باشید.

تأخیر (Latency). مدار کلاینت شامل سه رله است و سمت سرویس نیز سه رله دیگر اضافه می‌کند؛ بنابراین ضربات کلید شما تقریباً از شش ماشین که به‌صورت تصادفی در سراسر جهان انتخاب شده‌اند عبور می‌کند. تایپ تعاملی دارای تأخیر محسوس است و کپی فایل‌ها به‌کندی انجام می‌شود. WireGuard تنها یک گام (hop) اضافه می‌کند. مورد خود را با time ssh myvps 'echo ok' اندازه‌گیری کنید، زیرا این عدد به مداری که tor ساخته است بستگی دارد و با ساخت مدار جدید توسط tor، تغییر می‌کند.

یک دیمون در فضای کاربری (Userspace) در مسیر بحرانی. WireGuard در هسته (kernel) قرار دارد و همزمان با شبکه بالا می‌آید. Tor یک پردازش است که باید شروع شود، bootstrap شود و پیش از کارکردن هر چیزی، به یک guard relay متصل شود. وقتی این فرآیند شکست می‌خورد، شما باید از طریق کنسول ارائه‌دهنده اقدام کنید.

دقت ساعت سیستم. توصیف‌گرهای سرویس onion بر اساس بازه‌های زمانی منتشر می‌شوند، بنابراین اگر ساعت سیستم به‌شدت اشتباه باشد، جستجوی آدرس بدون هیچ پیام خطای واضحی شکست می‌خورد. timedatectl باید مقدار System clock synchronized: yes را گزارش دهد.

آنچه در ازای این موارد به دست می‌آورید، دسترسی‌پذیری است که دیگر به صحت قوانین فایروال وابسته نیست. هیچ پورتی برای اسکن و هیچ بنری برای دریافت وجود ندارد؛ آدرس خود یک کلید عمومی است، بنابراین نقطه پایانی پیش از شروع SSH، هویت خود را اثبات می‌کند.

پاسخ عملی معمولاً استفاده از هر دو است. WireGuard را به عنوان مسیر روزمره اجرا کنید و سرویس onion را به عنوان مسیری نگه دارید که وقتی پیکربندی WireGuard اشتباه است، همچنان کار می‌کند. این کار باعث می‌شود تنها یک پورت UDP باز بماند، نه یک پورت SSH عمومی. هیچ‌کدام از این‌ها جایگزین مقاوم‌سازی خود sshd نمی‌شود: احراز هویت فقط با کلید و ورود غیر-root همچنان اهمیت دارند، زیرا سرویس onion فقط از مسیر شبکه محافظت می‌کند و نه چیزی فراتر از آن.

حالت‌های شکست و خطاهایی که مشاهده خواهید کرد

Tor هرگز از Bootstrapped 0% عبور نمی‌کند. ترافیک خروجی مسدود شده است یا ساعت سیستم اختلاف زیادی دارد. سیاست خروجی را با sudo ufw status verbose بررسی کنید و سپس timedatectl را اجرا نمایید.

systemctl status tor عبارت active (exited) را نمایش می‌دهد. این وضعیت در Debian و Ubuntu عادی است. در عوض tor@default را مطالعه کنید.

توصیف‌گر (descriptor) پیدا نمی‌شود. Tor خطای توسعه‌یافته SOCKS با کد F0 یعنی "Onion Service Descriptor Can Not be Found" را برمی‌گرداند. یا توصیف‌گر هنوز منتشر نشده است که پس از reload کمی زمان می‌برد، یا سرویس tor روی سرور در حال اجرا نیست.

کد F4، "Onion Service Missing Client Authorization". کلاینت هیچ .auth_private منطبقی که tor بتواند از آن استفاده کند ندارد. بررسی کنید که ClientOnionAuthDir در torrc موجود باشد، مجوز دایرکتوری 0700 باشد، نام فایل به .auth_private ختم شود و debian-tor دسترسی خواندن آن را داشته باشد.

کد F5، "Onion Service Wrong Client Authorization". کلید خصوصی با فایل .auth روی سرور مطابقت ندارد. وجود یک = اضافی یا یک خط جدید (newline) ناخواسته در رشته base32 باعث بروز این خطا می‌شود.

nc: invalid option -- 'X'. نسخه GNU از netcat به جای نسخه OpenBSD نصب شده است. sudo apt install -y netcat-openbsd را اجرا کنید.

Could not resolve hostname. دستور ssh تلاش کرد از DNS معمولی استفاده کند که پاسخی برای .onion ندارد، بنابراین ProxyCommand هرگز اجرا نشد. الگوی Host در ~/.ssh/config با نامی که تایپ کرده‌اید مطابقت ندارد.

Permission denied (publickey). تونل کار کرده و کار tor تمام شده است. با این مورد مانند یک مشکل عادی عدم دسترسی publickey برخورد کنید و tor را از معادله خارج کنید.

FAQ

آیا onion service واقعاً به معنای نداشتن هیچ پورت باز روی VPS است؟

بله، زمانی که sshd به 127.0.0.1 متصل شود و فایروال ترافیک ورودی را مسدود کند. Tor یک اتصال TCP خروجی به یک relay برقرار می‌کند و نشست شما از طریق آن بازمی‌گردد، بنابراین هیچ چیزی روی سرور اتصالی را روی آدرس عمومی نمی‌پذیرد. این موضوع را با ss -tlnp روی سرور و یک اسکن پورت از جای دیگر تأیید کنید. فایروال شبکه خودِ ارائه‌دهنده در پنل کنترل را فراموش نکنید؛ این یک کنترل جداگانه از ufw است و باید آن هم بسته شود.

آیا آدرس .onion به تنهایی برای امنیت SSH کافی است؟

خیر. این آدرس 56 کاراکتری است و نمی‌توان آن را حدس زد یا از طریق سیستم دایرکتوری استخراج کرد، بنابراین مانند یک راز عمل می‌کند، اما از طریق تاریخچه shell و فایل‌های پیکربندی نشت می‌کند. از v3 client authorisation استفاده کنید. با این کار، توصیف‌گر سرویس با کلید کلاینت شما رمزنگاری می‌شود، بنابراین کسی که فقط آدرس را دارد، خطای توسعه‌یافته F4 را دریافت می‌کند و هرگز به sshd نمی‌رسد.

اگر tor پس از reboot بالا نیاید چه اتفاقی می‌افتد؟

دسترسی SSH خود را کاملاً از دست می‌دهید، زیرا آدرس onion تنها راه ورود است. به همین دلیل است که کنسول ارائه‌دهنده باید پیش از بستن پورت 22 تست شود. Tor همچنین پس از بوت شدن به زمان برای bootstrap نیاز دارد، بنابراین آدرس دیرتر از زمانی که ماشین به ping پاسخ می‌دهد، در دسترس قرار می‌گیرد. اگر هرگز پاسخ نداد، از طریق کنسول وارد شوید و sudo journalctl -u tor@default -b را بخوانید؛ در آنجا خطای نحوی torrc یا مشکل مجوز در /var/lib/tor/ssh ثبت شده است.

آیا SSH روی Tor کندتر از WireGuard است؟

بله، با اختلاف زیاد. اتصال به یک onion service از حدود شش relay که به‌طور تصادفی انتخاب شده‌اند عبور می‌کند، در حالی که WireGuard یک hop رمزنگاری‌شده مستقیم به سرور شماست. تایپ کردن حس تأخیر دارد و انتقال فایل‌ها کند است. یک پیکربندی رایج، استفاده از WireGuard برای کارهای روزمره و نگهداری onion service به‌عنوان مسیر اضطراری است که در صورت خرابی پیکربندی VPN همچنان کار می‌کند.