Tor onion service वरून SSH, inbound port शिवाय

Tor onion service वरून SSH वापरल्याने काय बदलते

Tor onion service वरून SSH वापरल्यास कोणत्याही port वर inbound connection स्वीकारत नसलेल्या VPS चे प्रशासन करता येते. Server Tor network शी outbound connection स्थापित करतो आणि ती connection सुरू ठेवतो. तुमचे SSH session त्याच connection मार्गे परत येते. त्यामुळे public IP address वर कोणत्याही सेवेला listen करण्याची गरज राहत नाही.

याचा log वर त्वरित परिणाम दिसतो. Public SSH port असलेल्या machine वर scanners कडून दररोज password च्या हजारो अयशस्वी प्रयत्नांची नोंद होते. sshd ला onion service मागे ठेवा आणि firewall वर inbound traffic drop करा. त्यानंतर /var/log/auth.log मध्ये तुम्ही सुरू केलेल्या sessions चीच नोंद होते.

याची किंमत अशी आहे की प्रत्येक admin session च्या मार्गात tor असते. हा userspace daemon आहे. प्रत्येक reboot नंतर तुम्ही login करण्यापूर्वी तो सुरू होऊन bootstrap होणे आवश्यक असते. Port बंद करण्यापूर्वी याचे नियोजन करा, कारण येथे failure mode म्हणजे प्रत्यक्ष प्रवेश नसलेल्या machine वरील access गमावणे होय.

काहीही बदल करण्यापूर्वी पुन्हा प्रवेश करण्याचा मार्ग तयार करा

SSH शिवाय काम करणारा पुनर्प्राप्ती मार्ग तयार होईपर्यंत प्रक्रिया सुरू करू नका.

आता तुमच्या provider चे console उघडा. Control panel मधील VNC किंवा serial console वापरून त्यात login करा. root password माहीत नसेल, तर प्रथम panel मधून root password reset करा आणि ते कार्यरत असल्याची खात्री करा. तुम्ही कधीही तपासलेले नसलेले console हा पुनर्प्राप्ती मार्ग नाही.

खालील क्रम महत्त्वाचा आहे. पुढील पायरी सुरू करण्यापूर्वी प्रत्येक पायरीची पडताळणी केली जाते आणि onion route कार्यरत होईपर्यंत port 22 उघडा ठेवला जातो.

1. tor install करा आणि ते 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 बदलानंतरही established session सुरू राहते. त्यामुळे तो तुमचा पहिला rescue मार्ग आहे.

सर्व्हरवर tor स्थापित करा

Ubuntu स्वतःच्या repository मध्ये tor उपलब्ध करून देते आणि त्यातील build अनेकदा जुन्या आवृत्तीचा असतो. Tor Project च्या repository मध्ये त्यांच्या documentation मध्ये वर्णन केलेली आवृत्ती असते. ती repository त्यांच्या 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 तो codename दाखवते (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 सुरू करणे, थांबवणे आणि reload करणे यामुळे 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 ला सार्वजनिक address वर listening थांबवता येते. त्या दुसऱ्या ओळीत 127.0.0.1:80 वरील web server निर्दिष्ट करा. त्याच दोन directives मुळे onion address वर site प्रकाशित करता येते, आणि tor install केल्यानंतर चालवण्यासाठी ही एक उपयुक्त दुसरी service आहे.

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

यातून 56 base32 characters आणि त्यानंतर .onion छापले जाते. हे characters service ची encoded स्वरूपातील public key आहेत. यासाठी कोणतीही certificate authority किंवा name registration आवश्यक नाही.

tor ला /var/lib/tor/ssh/ स्वतः तयार करू द्या. ते चुकीच्या owner सह manually तयार केल्यास किंवा 0700 पेक्षा सैल mode दिल्यास tor ते वापरण्यास नकार देतो आणि journal मध्ये directory permissions खूप सैल असल्याचे नोंदवते. त्यातील files ही service identity आहेत: hs_ed25519_secret_key हाच address आहे. त्या directory चा mode 600 ठेवून backup घ्या आणि ती प्रत बॉक्सच्या बाहेर सुरक्षित ठेवा. ती हरवल्यास नवीन address तयार करावा लागेल आणि प्रत्येक client वर configuration बदलावे लागेल.

वर्कस्टेशनवरून कनेक्ट करा

तुमच्या 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 स्थानिक 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 स्वीकारा. यानंतर नेहमीची SSH key हाताळणी कोणताही बदल न करता लागू होते. Transport बदलला आहे. Authentication बदललेले नाही.

एकदाच वापरायचे असल्यास config entry वगळू शकता: torsocks ssh admin@xxxxx.onion तेच काम करते.

v3 क्लायंट अधिकृतता जोडा

सध्या, ज्याला हा पत्ता कळतो तो तुमच्या SSH banner पर्यंत पोहोचून अंदाज घेण्यास सुरुवात करू शकतो. Onion पत्ते directory system मधून enumerate करता येत नाहीत, त्यामुळे हा पत्ता secret प्रमाणे कार्य करतो. मात्र तो सामान्य मार्गांनी उघड होऊ शकतो: shell history किंवा git repository मध्ये commit केलेल्या config files द्वारे. Client authorisation ही त्रुटी दूर करते. सेवा तिचा descriptor client key ने encrypted स्वरूपात प्रकाशित करते. त्यामुळे पत्ता माहीत असला तरी key नसलेली व्यक्ती सेवा शोधूही शकत नाही.

क्लायंटवर x25519 key pair तयार करा. हे 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

त्या ओळींच्या प्रकाशित आवृत्तीत base64pem -d वापरले आहे. Stock Ubuntu install मध्ये ते उपलब्ध नसते. त्यामुळे command base64pem: command not found सह थांबते. GNU base64 -d तोच PEM body decode करते. म्हणून ते वापरा.

सर्व्हरवर 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 वाचल्या जातात. ती file laptop.auth.txt म्हणून save केल्यास tor ती skip करतो आणि log मध्ये फक्त file "must end in .auth" असा warning ठेवतो. तुम्ही journal वाचला नाही, तर हे लक्षात येणार नाही. परिणामी, पत्ता माहीत असलेल्या कोणालाही सेवा उपलब्ध राहते.

क्लायंटवर private key install करा. Ubuntu वर tor daemon debian-tor user म्हणून चालतो आणि तुमच्या home directory मधील files वाचू शकत नाही. त्यामुळे त्या user ला access करता येईल अशा ठिकाणी directory ठेवा.

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

क्लायंटच्या /etc/tor/torrc मध्ये ClientOnionAuthDir /var/lib/tor/onion_auth जोडा आणि tor reload करा. त्याऐवजी tor तुमच्या स्वतःच्या user म्हणून चालवत असल्यास, उदाहरणार्थ macOS वरील Homebrew build मध्ये, ClientOnionAuthDir ला mode 0700 असलेल्या ~/.tor/onion_auth कडे निर्देशित करा.

त्या file मधील address हा .onion suffix शिवाय 56 characters चा असतो. काम पूर्ण झाल्यावर /tmp/k1.prv.pem आणि /tmp/k1.prv.key delete करा.

आता दोन्ही दिशांनी चाचणी करा. ssh myvps ने अद्याप connect झाले पाहिजे. कोणतीही key नसलेल्या machine वरून तोच address वापरल्यास connection fail झाले पाहिजे. ही failure म्हणजे authorisation सक्रिय असल्याचा पुरावा आहे.

पोर्ट 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 ने ती रद्द करा.

त्यानंतर सार्वजनिक address वर ऐकणारे sshd थांबवा. Ubuntu 24.04 मध्ये ssh, default म्हणून socket unit द्वारे सक्रिय होते. त्यामुळे listening socket चे नियंत्रण sshd कडे नसून ssh.socket कडे असते. sshd_config मधील ListenAddress अजूनही लागू होते. Ubuntu चे openssh package systemd generator पुरवते. हा generator sshd_config वाचतो आणि त्यानुसार socket चे listen addresses लिहितो. हे फक्त systemd आपले generators पुन्हा चालवते तेव्हाच घडते. त्यामुळे ListenAddress मधील बदल sudo systemctl daemon-reload आणि sudo systemctl restart ssh.socket नंतर लागू होतो; sshd restart केल्यानंतर नाही. खालील पायऱ्या socket थेट सेट करतात. त्यामुळे वरील rescue timer एक file delete करून हा बदल पूर्ववत करू शकतो. तुमची स्थिती कोणती आहे ते तपासा.

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 rule व्यवस्थापन आहे. प्रथम sudo ufw status numbered चालवा आणि त्यात दिसणारा SSH rule delete करा.

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

बाहेर जाणारा traffic अनुमत ठेवा. Tor, 443 आणि 9001 सारख्या ports वर relay कडे बाहेरून connection करतो. त्यामुळे outbound साठी default-deny policy ठेवल्यास tor bootstrapping थांबते आणि त्याच वेळी तुमच्याकडे उरलेला एकमेव प्रवेशमार्गही बंद होतो. बहुतेक providers control panel मध्ये स्वतंत्र network firewall देखील चालवतात. तेथेही 22 बंद करा. अन्यथा ufw काहीही दाखवत असला तरी port reachable राहतो.

या box वर Docker चालत असल्यास, काम पूर्ण झाले असे समजण्यापूर्वी published ports तपासा. Docker त्याचे स्वतःचे rules त्याच tables मध्ये लिहितो आणि container ports थेट ufw च्या पलीकडे publish करतो. त्यामुळे ufw deny policy ही संपूर्ण स्थिती दर्शवत नाही.

रीबूट केल्याशिवाय त्यावर विश्वास ठेवू नका

systemctl is-enabled tor@default
sudo reboot

पहिल्या command मध्ये सेवा enabled असल्याचे दिसत नसेल, तर रीबूट करण्यापूर्वी sudo systemctl enable tor@default चालवा. दोन मिनिटे थांबा आणि नंतर ssh myvps चालवा. boot नंतर Tor ला bootstrap होण्यासाठी वेळ लागतो. त्यामुळे मशीन सुरू झाल्यानंतर काही वेळाने onion address कडून प्रतिसाद मिळू लागतो.

सेवा पुन्हा सुरू झाली नाही, तर console उघडा आणि sudo journalctl -u tor@default -b वाचा. torrc मधील syntax error किंवा directory permission ची समस्या तेथे दिसते. लागू करण्यापूर्वी torrc मधील बदल तपासण्यासाठीही तुम्ही हे वापरू शकता.

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

WireGuard tunnel च्या तुलनेत याची किंमत

तुमच्या स्वतःच्या VPS वरील WireGuard VPNच्या तुलनेत onion service अधिक धीम्या गतीची आणि कमी अंदाज करता येण्यासारखी असते. हा पर्याय स्वीकारण्यापूर्वी या तडजोडीचा स्वतःशी प्रामाणिकपणे विचार करा.

Latency. Client circuit मध्ये तीन relays असतात आणि service side वर आणखी तीन relays जोडले जातात. त्यामुळे तुमच्या कीस्ट्रोक्सचा प्रवास जगभर यादृच्छिकपणे निवडलेल्या सुमारे सहा machines मधून होतो. Interactive typing मध्ये स्पष्ट विलंब जाणवतो आणि file copies धीम्या होतात. WireGuard मध्ये एक hop असतो. तुमच्या परिस्थितीचे मोजमाप time ssh myvps 'echo ok' ने करा, कारण हा आकडा tor ने कोणता circuit तयार केला यावर अवलंबून असतो आणि tor ने दुसरा circuit तयार केल्यावर बदलतो.

Critical path मधील userspace daemon. WireGuard kernel मध्ये चालते आणि network सोबत सुरू होते. Tor ही अशी process आहे जी सुरू झाली पाहिजे, bootstrap झाले पाहिजे आणि कोणतेही काम सुरू होण्यापूर्वी guard relay पर्यंत पोहोचली पाहिजे. ती अयशस्वी झाल्यास तुम्ही provider console वर अवलंबून राहता.

Clock accuracy. Onion service descriptors ठरावीक time periods शी संबंधित प्रकाशित केले जातात. त्यामुळे clock मध्ये मोठी चूक असल्यास कोणताही स्पष्ट संदेश न देता address lookup अयशस्वी होतो. timedatectl ने System clock synchronized: yes दाखवले पाहिजे.

याच्या बदल्यात तुम्हाला अशी exposure protection मिळते जी firewall rule योग्य आहे की नाही यावर अवलंबून राहत नाही. Scan करण्यासाठी कोणताही port नसतो आणि मिळवण्यासाठी कोणताही banner नसतो. तसेच address स्वतः public key असल्यामुळे SSH सुरू होण्यापूर्वीच endpoint आपली identity सिद्ध करतो.

व्यवहार्य उत्तर सहसा दोन्ही वापरणे हेच असते. दैनंदिन मार्ग म्हणून WireGuard चालवा आणि WireGuard configuration चुकीची असतानाही काम करणारा मार्ग म्हणून onion service ठेवून द्या. त्यामुळे public SSH port ऐवजी एक UDP port उघडा ठेवावा लागतो. यापैकी कोणतीही गोष्ट sshd ला स्वतः harden करण्याची जागा घेत नाही. Key-only authentication आणि non-root login अजूनही महत्त्वाचे आहेत, कारण onion service फक्त network path चे संरक्षण करते; त्यापलीकडील कोणत्याही गोष्टीचे नाही.

अपयशाच्या स्थिती आणि दिसणाऱ्या त्रुटी

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 कडे tor वापरू शकेल अशी जुळणारी .auth_private नाही. ClientOnionAuthDir torrc मध्ये आहे का, directory चा mode 0700 आहे का, filename .auth_private ने संपते का आणि debian-tor ती वाचू शकते का ते तपासा. चुकीच्या स्वरूपाची key देखील हे कारण असू शकते: base32 string च्या शेवटी असलेले = किंवा तिच्यामधील अनावश्यक newline यामुळे tor file load करताना ती नाकारतो. Client log मध्ये base32 private key ची length invalid असल्याचे किंवा key decode करता येत नसल्याचे दिसते.

F5, "Onion Service Wrong Client Authorization". Tor ने योग्य स्वरूपाची private key load केली आहे; परंतु ती server वरील .auth file शी जुळत नाही. त्यामुळे descriptor decrypt करता येणार नाही. सामान्य कारणे म्हणजे वेगळ्या pair मधील key किंवा client सेट केल्यानंतर बदललेली server .auth file.

nc: invalid option -- 'X'. OpenBSD आवृत्तीऐवजी GNU netcat install केलेले आहे. sudo apt install -y netcat-openbsd चालवा.

Could not resolve hostname. ssh ने सामान्य DNS वापरण्याचा प्रयत्न केला. .onion साठी DNS कडे उत्तर नसल्यामुळे ProxyCommand कधीही चालले नाही. ~/.ssh/config मधील Host pattern तुम्ही टाइप केलेल्या नावाशी जुळत नाही.

Permission denied (publickey). Tunnel यशस्वी झाला आणि tor चे काम पूर्ण झाले. याला सामान्य permission denied publickey समस्या समजा आणि tor ला यातून वगळा.

FAQ

onion service म्हणजे माझ्या VPS वर कोणतेही खुले पोर्ट नसणे का?

होय. 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 करून याची पडताळणी करा. Control panel मधील provider चा स्वतःचा network firewall विसरू नका. तो ufw पासून स्वतंत्र असतो आणि तोही बंद स्थितीत ठेवावा लागतो.

SSH साठी .onion address स्वतःपुरती पुरेशी सुरक्षा आहे का?

नाही. हा address 56 characters चा असतो आणि directory system मधून त्याचा अंदाज लावता किंवा enumeration करता येत नाही. त्यामुळे तो secret प्रमाणे कार्य करतो. मात्र तो shell history आणि config files मधून उघड होऊ शकतो. v3 client authorisation जोडा. त्यामध्ये service descriptor तुमच्या client key साठी encrypted केला जातो. त्यामुळे फक्त address असलेल्या व्यक्तीला extended error F4 मिळतो आणि ती sshd पर्यंत पोहोचतच नाही.

रीबूटनंतर tor सुरू झाले नाही तर काय होते?

तुमचा SSH access पूर्णपणे बंद होतो, कारण त्या वेळी onion address हाच प्रवेशाचा एकमेव मार्ग असतो. म्हणून port 22 बंद करण्यापूर्वी provider console तपासणे आवश्यक आहे. Boot नंतर Tor ला bootstrap होण्यासाठी वेळ लागतो. त्यामुळे 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 यादृच्छिकपणे निवडलेल्या सुमारे सहा relays मधून जाते. WireGuard मध्ये तुमच्या server पर्यंत एकच encrypted hop असतो. Typing करताना विलंब जाणवतो आणि transfers धीमे होतात. सामान्यतः दैनिक कामासाठी WireGuard वापरले जाते आणि onion service हा emergency route म्हणून ठेवला जातो. त्यामुळे VPN configuration बिघडली तरी त्याद्वारे access मिळू शकतो.