Tor onion service کے ذریعے SSH، بغیر open ports

SSH over a Tor onion service سے کیا تبدیل ہوتا ہے

SSH over a Tor onion service کے ذریعے آپ ایسے VPS کا انتظام کر سکتے ہیں جو کسی بھی port پر inbound connection قبول نہیں کرتا۔ سرور Tor network سے outbound connection قائم کرتا ہے اور اسے برقرار رکھتا ہے۔ آپ کا SSH session اسی connection کے ذریعے واپس سرور تک پہنچتا ہے، اس لیے public IP address پر کسی سروس کو listen کرنے کی ضرورت نہیں رہتی۔

اس کا اثر log میں فوراً نظر آتا ہے۔ public SSH port والا server scanners کی جانب سے روزانہ ہزاروں failed password attempts ریکارڈ کرتا ہے۔ sshd کو onion service کے پیچھے منتقل کریں اور firewall پر inbound traffic روک دیں؛ اس کے بعد /var/log/auth.log صرف وہی sessions ریکارڈ کرتا ہے جو آپ نے شروع کیے ہیں۔

اس کا نقصان یہ ہے کہ tor ہر admin session کے راستے میں موجود رہتا ہے۔ یہ ایک userspace daemon ہے جسے ہر reboot کے بعد start اور bootstrap ہونا پڑتا ہے، تب ہی آپ login کر سکتے ہیں۔ port بند کرنے سے پہلے اس کا منصوبہ بنائیں، کیونکہ یہاں failure mode ایسی machine تک رسائی کھو دینا ہے جس تک آپ جسمانی طور پر نہیں پہنچ سکتے۔

کسی بھی تبدیلی سے پہلے واپس داخل ہونے کا راستہ یقینی بنائیں

اس وقت تک کام شروع نہ کریں جب تک آپ کے پاس ایسا recovery path نہ ہو جو SSH استعمال نہ کرتا ہو۔

ابھی اپنے provider کا console کھولیں، یعنی control panel میں موجود VNC یا serial console، اور اس کے ذریعے login کریں۔ اگر root password معلوم نہیں ہے تو پہلے panel سے root password reset کریں اور تصدیق کریں کہ وہ کام کرتا ہے۔ ایسا console جسے آپ نے کبھی test نہ کیا ہو، recovery path نہیں ہے۔

ذیل کی ترتیب اہم ہے۔ اگلا مرحلہ شروع ہونے سے پہلے ہر مرحلے کی کامیابی کی تصدیق کی جاتی ہے، اور onion route کے کام کرنے تک port 22 کھلا رہتا ہے۔

1. tor انسٹال کریں اور تصدیق کریں کہ وہ bootstrap مکمل کر رہا ہے۔
2. onion service define کریں اور اس کا address پڑھیں۔
3. port 22 کھلا رہتے ہوئے onion کے ذریعے connect کریں۔
4. client authorisation شامل کریں، پھر دوبارہ connect کریں۔
5. sshd کو loopback سے bind کریں اور port 22 بند کریں۔
6. reboot کریں، پھر دوبارہ onion کے ذریعے connect کریں۔

پورے عمل کے دوران موجودہ SSH session کھلا رکھیں۔ قائم شدہ session ایسی firewall تبدیلی کے باوجود برقرار رہتا ہے جو نیا session روک دے، اس لیے یہی آپ کا پہلا rescue راستہ ہے۔

سرور پر tor انسٹال کریں

Ubuntu اپنی repository میں tor فراہم کرتا ہے، لیکن اس کی build اکثر پرانی ہوتی ہے۔ Tor Project کی repository میں وہ version موجود ہوتا ہے جس کی وضاحت ان کی documentation میں کی گئی ہے۔ اسے ان کی apt repository guide میں دی گئی commands سے شامل کریں۔

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 آپ کے release codename کو استعمال کرتا ہے، جسے lsb_release -cs ظاہر کرتا ہے (Ubuntu 24.04 پر noble)۔

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

Log کا اختتام Bootstrapped 100% (done) پر ہونا چاہیے۔ اگر اس سے پہلے رک جائے تو tor network تک نہیں پہنچ سکتا۔ اس کی تقریباً ہمیشہ وجہ outbound firewall rule یا system clock کا بہت زیادہ غلط ہونا ہوتی ہے۔

Unit کا نام گمراہ کن ہے۔ systemctl status tor ہر چیز درست ہونے کے باوجود Active: active (exited) رپورٹ کرتا ہے، کیونکہ Debian اور Ubuntu tor کو multi-instance master unit کے طور پر package کرتے ہیں۔ اس unit کا واحد کام اصل instance کو شروع کرنا ہے۔ Daemon خود tor@default.service کے طور پر چلتا ہے۔ status اور journalctl کے لیے یہی نام استعمال کریں۔ tor کو start، stop اور reload کرنے کی commands پھر بھی اسی instance تک پہنچتی ہیں، اس لیے sudo systemctl reload tor آپ کی توقع کے مطابق کام کرتا ہے۔

پورٹ 22 کے لیے onion service متعین کریں

/etc/tor/torrc میں دو سطریں شامل کریں۔

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

دوسری سطر Tor کو بتاتی ہے کہ onion address پر virtual port 22 قبول کرے اور مشین پر موجود 127.0.0.1:22 سے رابطہ کرے۔ Tor، loopback کے ذریعے sshd تک پہنچتا ہے۔ اسی وجہ سے بعد میں sshd کو public address پر listening سے روکا جا سکتا ہے۔

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

یہ 56 base32 حروف کے بعد .onion دکھاتا ہے۔ یہ حروف service کی public key کو encoded شکل میں ظاہر کرتے ہیں۔ اس پورے عمل میں کسی certificate authority یا name registration کی ضرورت نہیں ہوتی۔

Tor کو /var/lib/tor/ssh/ خود بنانے دیں۔ اسے دستی طور پر غلط owner کے ساتھ بنائیں، یا اس کا mode 0700 سے زیادہ کھلا رکھیں، تو Tor اسے استعمال کرنے سے انکار کر دے گا اور journal directory کو too permissive قرار دے گا۔ اس کے اندر موجود files service identity ہیں: hs_ed25519_secret_key ہی address ہے۔ اس directory کا mode 600 کے ساتھ backup بنائیں اور copy کو مشین سے باہر محفوظ رکھیں، کیونکہ اسے کھو دینے کا مطلب نیا address بنانا اور ہر client پر configuration تبدیل کرنا ہے۔

اپنے workstation سے connect کریں

آپ کے workstation پر tor client ہونا چاہیے۔ اسے کسی configuration کی ضرورت نہیں ہوتی۔ Debian یا Ubuntu پر یہ sudo apt install -y tor netcat-openbsd ہے۔ اس کے بعد Tor 127.0.0.1:9050 پر SOCKS5 proxy کے طور پر listening کرتا ہے۔ SOCKS ایک عمومی proxy protocol ہے۔ اس کا version 5 IP address کے بجائے hostname بھی منتقل کر سکتا ہے۔ یہاں یہی بات اہم ہے۔

OpenSSH میں اپنا SOCKS client نہیں ہوتا۔ اس لیے connection بنانے کے لیے ایک helper program استعمال کیا جاتا ہے۔ اسے ~/.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 local tor کی طرف اشارہ کرتا ہے۔ %h onion name کو نام کی صورت میں tor کے حوالے کرتا ہے، تاکہ tor اسے network کے اندر resolve کرے۔ اس کے لیے OpenBSD netcat ہونا ضروری ہے۔ GNU netcat میں -X option موجود نہیں، اس لیے وہ nc: invalid option -- 'X' کے ساتھ رک جاتا ہے۔

ssh myvps

پہلا connection سست ہوتا ہے، کیونکہ tor پہلے circuit بناتا ہے۔ host key fingerprint کو اسی طرح قبول کریں جیسے کسی دوسرے connection میں کرتے ہیں۔ اس کے بعد معمول کی SSH key handling بغیر کسی تبدیلی کے لاگو ہوتی ہے۔ صرف transport تبدیل ہوا ہے۔ authentication تبدیل نہیں ہوئی۔

کسی ایک بار کے connection کے لیے آپ config entry چھوڑ سکتے ہیں: torsocks ssh admin@xxxxx.onion یہی کام کرتا ہے۔

v3 کلائنٹ authorisation شامل کریں

فی الحال، جس شخص کو address معلوم ہو، وہ آپ کے SSH banner تک پہنچ کر اندازے سے credentials آزمانا شروع کر سکتا ہے۔ Onion addresses کو directory system سے enumerate نہیں کیا جا سکتا، اس لیے address ایک secret جیسا رہتا ہے، لیکن عام طریقوں سے افشا ہو سکتا ہے: shell history یا کسی git repository میں commit کی گئی config files کے ذریعے۔ Client authorisation اس خلا کو بند کرتی ہے۔ سروس اپنا descriptor ایک client key کے لیے encrypted صورت میں publish کرتی ہے، اس لیے جس شخص کے پاس address تو ہو مگر key نہ ہو، وہ سروس کو locate بھی نہیں کر سکتا۔

Client پر x25519 key pair generate کریں۔ یہ Tor Project کی client authorisation guide میں دیا گیا pipeline ہے، البتہ ایک تبدیلی کے ساتھ۔

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

ان سطور کے published version میں base64pem -d استعمال ہوتا ہے، جو stock Ubuntu install میں موجود نہیں ہوتا۔ اس کے بعد command base64pem: command not found کے ساتھ رک جاتی ہے۔ GNU base64 -d اسی PEM body کو decode کرتا ہے، اس لیے اسے استعمال کریں۔

Server پر public key install کریں۔

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 پر ختم ہونے والی files پڑھی جاتی ہیں۔ اسے laptop.auth.txt کے نام سے save کریں، ورنہ tor بغیر کوئی error print کیے اس file کو ignore کر دے گا، اور سروس خاموشی سے address رکھنے والے ہر شخص کے لیے کھلی رہے گی۔

Client پر private key install کریں۔ Ubuntu میں tor daemon debian-tor user کے طور پر چلتا ہے اور آپ کی home directory میں files نہیں پڑھ سکتا، اس لیے directory کو ایسی جگہ رکھیں جہاں اس user کو رسائی حاصل ہو۔

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

Client کے /etc/tor/torrc میں ClientOnionAuthDir /var/lib/tor/onion_auth شامل کریں اور tor reload کریں۔ اگر آپ tor کو اپنے user کے طور پر چلاتے ہیں، مثلاً macOS پر Homebrew build، تو ClientOnionAuthDir کو ~/.tor/onion_auth کی طرف point کریں اور mode 0700 رکھیں۔

اس file کے اندر موجود address، .onion suffix کے بغیر 56 characters پر مشتمل ہے۔ کام مکمل ہونے پر /tmp/k1.prv.pem اور /tmp/k1.prv.key delete کریں۔

اب دونوں سمتوں کی testing کریں۔ ssh myvps کو اب بھی connect ہونا چاہیے۔ ایسی machine سے، جس کے پاس کوئی key نہ ہو، اسی address پر connection fail ہونا چاہیے۔ یہی failure اس بات کا ثبوت ہے کہ authorisation فعال ہے۔

port 22 بند کریں، اس ترتیب سے

پہلے حفاظتی انتظام کریں۔ اگر آپ خود کو باہر بند کر دیں تو یہ ایک command پندرہ منٹ بعد نیچے کی گئی دونوں تبدیلیاں واپس کر دیتی ہے۔

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 route اب بھی کام کر رہا ہے، تو اسے sudo systemctl stop ssh-rescue.timer سے منسوخ کریں۔

اب sshd کو public address پر listening سے روکیں۔ Ubuntu 24.04، ssh کو socket unit کے ذریعے فعال کرتا ہے، اس لیے sshd_config میں ListenAddress نظر انداز ہوتا ہے: listening socket کی ملکیت sshd کے پاس نہیں بلکہ ssh.socket کے پاس ہے۔ پہلے معلوم کریں کہ آپ کے سسٹم پر کون سی صورت موجود ہے۔

systemctl is-enabled ssh.socket

اگر اس سے enabled ظاہر ہو، تو sudo systemctl edit ssh.socket چلائیں اور یہ شامل کریں۔

[Socket]
ListenStream=
ListenStream=127.0.0.1:22

خالی ListenStream=، packaged unit سے وراثت میں ملنے والی value صاف کرتا ہے۔ اگر یہ line شامل نہ کریں تو public listener برقرار رکھتے ہوئے دوسرا listener شامل ہو جاتا ہے۔ اس مرحلے کے خاموشی سے ناکام ہونے کی یہ سب سے عام وجہ ہے۔

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 disabled ہو، تو ListenAddress 127.0.0.1 کو /etc/ssh/sshd_config.d/10-onion.conf میں شامل کریں، sudo systemctl restart ssh چلائیں، پھر اسی ss line سے دوبارہ جانچ کریں۔ دونوں صورتوں میں یہی output ثبوت فراہم کرتا ہے۔

اس کے بعد firewall ترتیب دیں۔ یہ VPS پر ufw rules کا عام انتظام ہے۔ پہلے sudo ufw status numbered چلائیں اور اس میں موجود SSH rule کو حذف کریں۔

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

outgoing traffic کی اجازت برقرار رکھیں۔ Tor، 443 اور 9001 جیسے ports پر relays سے outbound connections بناتا ہے۔ اس لیے outbound default-deny policy، tor bootstrapping روک دیتی ہے اور اسی وقت آپ کے اندر آنے کے واحد باقی راستے کو بھی ختم کر دیتی ہے۔ زیادہ تر providers، control panel میں الگ network firewall بھی چلاتے ہیں۔ وہاں بھی 22 بند کریں، ورنہ ufw کی رپورٹ سے قطع نظر port قابل رسائی رہے گا۔

اگر اس box پر Docker چل رہا ہے تو کام مکمل قرار دینے سے پہلے اس کے published ports چیک کریں۔ Docker انہی tables میں اپنے rules لکھتا ہے اور container ports کو براہ راست ufw کے باہر publish کرتا ہے، اس لیے ufw کی deny policy مکمل تصویر فراہم نہیں کرتی۔

اس پر اعتماد کرنے سے پہلے reboot کریں

systemctl is-enabled tor@default
sudo reboot

اگر پہلی command service کو enabled ظاہر نہ کرے تو reboot سے پہلے sudo systemctl enable tor@default چلائیں۔ دو منٹ انتظار کریں، پھر ssh myvps چلائیں۔ boot کے بعد Tor کو bootstrap مکمل کرنا ہوتا ہے، اس لیے onion address مشین کے up ہونے کے کچھ دیر بعد جواب دینا شروع کرتا ہے۔

اگر یہ دوبارہ کبھی دستیاب نہ ہو تو console کھولیں اور sudo journalctl -u tor@default -b پڑھیں۔ torrc syntax error یا directory permissions کا مسئلہ وہاں دکھائی دے گا۔ آپ torrc میں کی گئی ترمیم کو لاگو کرنے سے پہلے بھی چیک کر سکتے ہیں۔

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

WireGuard tunnel کے مقابلے میں اس کی اگلی لاگت

اپنے VPS پر WireGuard VPN کے مقابلے میں onion service سست اور کم قابلِ پیش گوئی ہوتی ہے۔ اسے فعال کرنے سے پہلے اس تبادلے کے بارے میں حقیقت پسند رہیں۔

تاخیر۔ Client circuit میں تین relays ہوتے ہیں اور service side پر مزید تین شامل ہوتے ہیں، اس لیے آپ کے keystrokes دنیا بھر میں تصادفی طور پر منتخب کیے گئے تقریباً چھ machines سے گزرتے ہیں۔ Interactive typing میں واضح تاخیر محسوس ہوتی ہے اور file copies سست ہوتی ہیں۔ WireGuard صرف ایک hop شامل کرتا ہے۔ اپنے معاملے کی پیمائش time ssh myvps 'echo ok' سے کریں، کیونکہ یہ قدر اس بات پر منحصر ہوتی ہے کہ tor نے کون سا circuit بنایا تھا، اور tor کے نیا circuit بنانے پر بدل جاتی ہے۔

اہم راستے میں userspace daemon۔ WireGuard kernel میں چلتا ہے اور network کے ساتھ شروع ہو جاتا ہے۔ Tor ایک ایسا process ہے جسے start اور bootstrap ہونا پڑتا ہے، اور کسی guard relay تک پہنچنا پڑتا ہے، تب ہی کوئی چیز کام کرتی ہے۔ ناکامی کی صورت میں آپ provider console پر منحصر رہتے ہیں۔

گھڑی کی درستگی۔ Onion service descriptors وقت کے ادوار کے مطابق publish ہوتے ہیں، اس لیے بہت غلط clock address lookup کو توڑ دیتی ہے اور کہیں بھی واضح message نہیں ملتا۔ timedatectl کو System clock synchronized: yes رپورٹ کرنا چاہیے۔

اس کے بدلے آپ کو ایسی exposure protection ملتی ہے جو firewall rule کے درست ہونے پر منحصر نہیں رہتی۔ Scan کرنے کے لیے کوئی port نہیں ہوتا اور حاصل کرنے کے لیے کوئی banner نہیں ہوتا۔ مزید یہ کہ address خود ایک public key ہوتا ہے، اس لیے SSH شروع ہونے سے پہلے ہی endpoint اپنی شناخت ثابت کر دیتا ہے۔

عملی جواب عموماً دونوں کا استعمال ہے۔ روزمرہ کے راستے کے طور پر WireGuard چلائیں، اور onion service کو اس route کے طور پر برقرار رکھیں جو WireGuard configuration غلط ہونے پر بھی کام کرے۔ اس طرح public SSH port کے بجائے صرف ایک UDP port کھلا رہتا ہے۔ ان میں سے کوئی بھی چیز خود sshd کو harden کرنے کا متبادل نہیں ہے: صرف key-based authentication اور non-root login اب بھی اہم ہیں، کیونکہ onion service صرف network path کو محفوظ بناتی ہے، اس سے آگے کسی چیز کو نہیں۔

خرابی کی صورتیں اور ظاہر ہونے والی errors

Tor کبھی Bootstrapped 0% سے آگے نہیں بڑھتا۔ Outbound traffic مسدود ہے، یا system clock میں خاصا فرق ہے۔ outgoing policy کو sudo ufw status verbose سے چیک کریں، پھر timedatectl چلائیں۔

systemctl status tor، active (exited) کہتا ہے۔ Debian اور Ubuntu میں یہ معمول کی بات ہے۔ اس کے بجائے tor@default پڑھیں۔

Descriptor نہیں مل سکتا۔ Tor SOCKS extended error F0 واپس کرتا ہے، "Onion Service Descriptor Can Not Be Found"۔ یا تو descriptor ابھی publish نہیں ہوا؛ reload کے بعد اس میں تھوڑا وقت لگتا ہے، یا server پر tor چل نہیں رہا۔

F4، "Onion Service Missing Client Authorization"۔ Client کے پاس ایسا matching .auth_private موجود نہیں جسے tor استعمال کر سکے۔ تصدیق کریں کہ ClientOnionAuthDir، torrc میں موجود ہے، directory کا mode 0700 ہے، filename کا اختتام .auth_private پر ہوتا ہے، اور debian-tor اسے پڑھ سکتا ہے۔

F5، "Onion Service Wrong Client Authorization"۔ Private key server پر موجود .auth file سے match نہیں کرتی۔ base32 string کے آخر میں موجود = یا اس کے اندر اضافی newline اس خرابی کا سبب بنتی ہے۔

nc: invalid option -- 'X'۔ GNU netcat انسٹال ہے، OpenBSD والا نہیں۔ sudo apt install -y netcat-openbsd چلائیں۔

Could not resolve hostname۔ ssh نے معمول کا DNS استعمال کرنے کی کوشش کی، لیکن .onion کے لیے کوئی جواب نہیں ملا، اس لیے ProxyCommand کبھی نہیں چلا۔ ~/.ssh/config میں موجود Host pattern، آپ کے درج کیے ہوئے نام سے match نہیں کرتا۔

Permission denied (publickey)۔ Tunnel کامیاب رہا اور tor کا کام مکمل ہو گیا۔ اسے معمول کے permission denied publickey مسئلے کے طور پر دیکھیں اور tor کو اس معاملے سے الگ رکھیں۔

FAQ

کیا onion service کا واقعی مطلب یہ ہے کہ میرے VPS پر کوئی public port کھلا نہیں؟

ہاں، جب sshd کو 127.0.0.1 پر bind کر دیا جائے اور firewall inbound traffic کو drop کرے۔ Tor ایک relay سے outbound TCP connection بناتا ہے، اور آپ کا session اسی کے ذریعے واپس آتا ہے۔ اس لیے server کے public address پر کوئی بھی چیز connection قبول نہیں کرتی۔ Server پر ss -tlnp چلا کر اور کسی دوسرے مقام سے port scan کر کے اس کی تصدیق کریں۔ Provider کے control panel میں موجود network firewall کو نہ بھولیں۔ یہ ufw سے الگ control ہے اور اسے بھی بند کرنا ضروری ہے۔

کیا SSH کے لیے .onion address اپنی جگہ کافی security فراہم کرتا ہے؟

نہیں۔ یہ address 56 characters پر مشتمل ہوتا ہے اور directory system سے اسے guess یا enumerate نہیں کیا جا سکتا، اس لیے یہ secret کی طرح کام کرتا ہے۔ لیکن یہ shell history اور config files کے ذریعے leak ہو سکتا ہے۔ v3 client authorisation شامل کریں۔ اس کے ذریعے service descriptor کو آپ کی client key کے لیے encrypt کیا جاتا ہے۔ یوں صرف address رکھنے والے شخص کو extended error F4 ملتا ہے اور وہ sshd تک بالکل نہیں پہنچ پاتا۔

اگر reboot کے بعد tor start نہ ہو تو کیا ہوتا ہے؟

آپ SSH access مکمل طور پر کھو دیتے ہیں، کیونکہ اس وقت اندر آنے کا واحد طریقہ onion address ہوتا ہے۔ اسی لیے port 22 بند کرنے سے پہلے provider console کو test کرنا ضروری ہے۔ Boot کے بعد Tor کو bootstrap ہونے میں بھی وقت لگتا ہے، اس لیے address کا جواب machine کے ping کا جواب دینے کے بعد آتا ہے۔ اگر address کبھی جواب نہ دے تو console پر login کریں اور sudo journalctl -u tor@default -b پڑھیں۔ وہاں torrc syntax error یا /var/lib/tor/ssh پر permissions کا مسئلہ درج ہوتا ہے۔

کیا SSH over Tor، WireGuard سے سست ہے؟

ہاں، واضح فرق کے ساتھ۔ Onion service تک connection تقریباً چھ random منتخب کیے گئے relays سے گزرتا ہے، جبکہ WireGuard براہ راست آپ کے server تک ایک encrypted hop استعمال کرتا ہے۔ Typing میں تاخیر محسوس ہوتی ہے اور transfers سست ہوتے ہیں۔ عام setup میں روزمرہ کام کے لیے WireGuard استعمال کیا جاتا ہے، جبکہ onion service کو emergency route کے طور پر برقرار رکھا جاتا ہے تاکہ VPN config خراب ہونے کے باوجود access موجود رہے۔