Tor onion service کے ذریعے SSH، کوئی open port نہیں

Tor onion service کے ذریعے SSH میں کیا تبدیلی آتی ہے

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

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

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

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

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

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

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

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

پورے عمل کے دوران موجودہ SSH session کھلا رکھیں۔ قائم شدہ session ایسی firewall تبدیلی کے باوجود برقرار رہتا ہے جو نئی connection کو روک دے۔ اس لیے یہ آپ کی پہلی 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) پر ہونا چاہیے۔ اگر output اسی سے پہلے رک جائے تو tor network تک نہیں پہنچ سکتا۔ اس کی تقریباً ہمیشہ وجہ outbound firewall rule یا system clock کا شدید غلط ہونا ہوتی ہے۔

unit name ایک trap ہے۔ 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 قبول کرے اور اسے اس machine پر 127.0.0.1:22 سے connect کرے۔ Tor loopback کے ذریعے sshd تک پہنچتا ہے۔ اسی لیے بعد میں sshd کو public address پر listening سے روکا جا سکتا ہے۔ دوسری سطر میں 127.0.0.1:80 پر موجود web server کا پتہ دیں۔ یہی دونوں directives onion address پر site publish کرتی ہیں، اور Tor install ہونے کے بعد یہ ایک مفید دوسری service ہو سکتی ہے۔

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

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

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

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

آپ کے workstation پر tor client درکار ہے، جس کے لیے کسی configuration کی ضرورت نہیں۔ Debian یا Ubuntu پر یہ sudo apt install -y tor netcat-openbsd ہے۔ اس کے بعد Tor 127.0.0.1:9050 پر SOCKS5 proxy کے طور پر listen کرتا ہے۔ 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 مقامی tor کی طرف اشارہ کرتا ہے۔ %h onion name کو 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 نہیں۔

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

v3 کلائنٹ کی اجازت شامل کریں

موجودہ حالت میں، جس شخص کو بھی address معلوم ہو وہ آپ کے SSH banner تک پہنچ کر اندازے سے keys آزما سکتا ہے۔ 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

صرف وہ files پڑھی جاتی ہیں جو .auth پر ختم ہوتی ہوں۔ اسے laptop.auth.txt کے نام سے save کریں، ورنہ tor کوئی error ظاہر کیے بغیر اس file کو نظرانداز کر دے گا اور سروس خاموشی سے 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 کو mode 0700 کے ساتھ ~/.tor/onion_auth کی طرف point کریں۔

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

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

پورٹ 22 کو اس ترتیب سے بند کریں

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

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 سے منسوخ کریں۔

اگلا مرحلہ یہ ہے کہ public address پر sshd کی 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 سے inherited value صاف کرتا ہے۔ اگر یہ لائن شامل نہ کی جائے تو public listener برقرار رہتا ہے اور دوسرا listener شامل ہو جاتا ہے۔ یہ اس مرحلے کے ناکام ہونے کی سب سے عام وجہ ہے، اور عموماً کوئی واضح error بھی ظاہر نہیں ہوتا۔

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

اب firewall کی باری ہے۔ یہ VPS پر عام ufw rule management ہے۔ پہلے 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 کو allowed رہنے دیں۔ Tor relays سے 443 اور 9001 جیسے ports پر باہر سے connection قائم کرتا ہے۔ اس لیے outbound کے لیے default-deny policy Tor کے bootstrapping کو روک دیتی ہے اور اسی وقت اندر آنے کا آپ کا واحد باقی راستہ بھی ختم کر دیتی ہے۔ زیادہ تر providers control panel میں الگ network firewall بھی چلاتے ہیں۔ وہاں بھی 22 بند کریں، ورنہ ufw کی رپورٹ کچھ بھی ہو، port قابل رسائی رہے گا۔

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

ریبوٹ سے پہلے اس پر بھروسا نہ کریں

systemctl is-enabled tor@default
sudo reboot

اگر پہلی کمانڈ service کو enabled ظاہر نہ کرے تو reboot کرنے سے پہلے sudo systemctl enable tor@default چلائیں۔ 2 منٹ انتظار کریں، پھر ssh myvps چلائیں۔ Tor کو boot کے بعد 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 سست اور کم قابلِ پیش گوئی ہوتی ہے۔ اسے استعمال کرنے سے پہلے اس سمجھوتے کا حقیقت پسندانہ جائزہ لیں۔

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

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

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

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

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

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

Tor کبھی بھی Bootstrapped 0% سے آگے نہیں بڑھتا۔ Outbound traffic مسدود ہے، یا clock میں بہت زیادہ فرق ہے۔ sudo ufw status verbose سے outgoing policy دیکھیں، پھر 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 پر کوئی open 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 ہے اور اسے بھی بند کرنا ضروری ہے۔

کیا .onion address خود SSH کے لیے کافی security فراہم کرتا ہے؟

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

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

آپ SSH access مکمل طور پر کھو دیتے ہیں، کیونکہ اس صورت میں داخل ہونے کا واحد راستہ onion address ہوتا ہے۔ اسی لیے port 22 بند کرنے سے پہلے provider console کو آزمانا ضروری ہے۔ Boot کے بعد Tor کو bootstrap ہونے میں بھی وقت لگتا ہے، اس لیے address کا جواب machine کے ping کا جواب دینے کے بعد آتا ہے۔ اگر یہ کبھی جواب نہ دے تو 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 خراب ہونے کے باوجود رسائی موجود رہے۔