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

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

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

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

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

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

تا زمانی که یک مسیر بازیابی (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) را گزارش می‌دهد، زیرا بسته‌های Debian و Ubuntu، نرم‌افزار tor را به عنوان یک 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 می‌تواند پس از آن، گوش دادن روی آدرس عمومی را متوقف کند.

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

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

اجازه دهید tor خودش /var/lib/tor/ssh/ را ایجاد کند. اگر آن را به‌صورت دستی و با مالک اشتباه یا سطح دسترسی (mode) بازتر از 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 اجرا می‌شود و نمی‌تواند فایل‌های موجود در دایرکتوری home شما را بخواند، بنابراین دایرکتوری را جایی قرار دهید که آن کاربر به آن دسترسی داشته باشد.

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 متصل می‌شود، بنابراین یک سیاست default-deny برای ترافیک خروجی، مانع از bootstrapping سرویس tor شده و در همان لحظه تنها راه دسترسی باقی‌مانده شما را نیز مسدود می‌کند. اکثر ارائه‌دهندگان خدمات، یک فایروال شبکه جداگانه در پنل کنترل خود دارند. پورت 22 را در آنجا نیز ببندید، در غیر این صورت پورت بدون توجه به گزارش ufw، همچنان در دسترس باقی می‌ماند.

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

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

systemctl is-enabled tor@default
sudo reboot

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

اگر سرویس بالا نیامد، کنسول را باز کرده و 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 یک پردازش است که باید شروع شود، بوت‌استرپ کند و پیش از کارکردن هر چیزی، به یک رله نگهبان (Guard relay) متصل شود. وقتی این فرآیند شکست می‌خورد، شما باید از طریق کنسول ارائه‌دهنده وارد عمل شوید.

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

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

پاسخ عملی معمولاً استفاده از هر دو است. WireGuard را به عنوان مسیر روزمره اجرا کنید و سرویس Onion را به عنوان مسیری نگه دارید که وقتی پیکربندی WireGuard اشتباه است، همچنان کار می‌کند. این کار باعث می‌شود به جای باز گذاشتن یک پورت عمومی SSH، تنها یک پورت UDP باز بماند. هیچ‌کدام از این‌ها جایگزین مقاوم‌سازی خودِ 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 روی سرور و یک port scan از جای دیگر تأیید کنید. فایروال شبکهٔ خودِ ارائه‌دهنده در پنل کنترل را فراموش نکنید؛ این یک کنترل جداگانه از ufw است و باید آن هم بسته شود.

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

خیر. این آدرس 56 کاراکتر است و نمی‌توان آن را حدس زد یا از سیستم دایرکتوری استخراج کرد، بنابراین مانند یک راز عمل می‌کند، اما از طریق تاریخچهٔ shell و فایل‌های پیکربندی نشت می‌کند. از v3 client authorisation استفاده کنید. با این کار، توصیف‌گر سرویس با کلید کلاینت شما رمزنگاری می‌شود، بنابراین کسی که فقط آدرس را دارد، خطای extended error 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 یک گام رمزنگاری‌شده مستقیم به سرور شماست. تایپ کردن حس تأخیر دارد و انتقال فایل‌ها کند است. یک پیکربندی رایج، استفاده از WireGuard برای کارهای روزمره و نگه داشتن onion service به عنوان مسیر اضطراری است که در صورت خرابی پیکربندی VPN، همچنان کار می‌کند.