SSH sa Tor onion service nang walang bukas na port

Mga pagbabago kapag gumagamit ng SSH sa pamamagitan ng Tor onion service

Pinapahintulutan ng SSH sa pamamagitan ng Tor onion service na mangasiwa ka ng VPS na walang tumatanggap na inbound connection sa anumang port. Kumokonekta ang server palabas sa Tor network at pinananatiling bukas ang koneksiyong iyon. Dumadaan dito ang iyong SSH session pabalik sa server, kaya walang kailangang makinig sa public IP address.

Agad makikita ang epekto sa log. Ang server na may public SSH port ay nakakatanggap ng libo-libong bigong pagtatangka ng password bawat araw mula sa mga scanner. Ilagay ang sshd sa likod ng onion service at i-drop ang inbound traffic sa firewall, at ang /var/log/auth.log ay magre-record na lamang ng mga session na ikaw ang nagsimula.

Ang kapalit nito ay nasa path ang tor ng bawat admin session. Isa itong userspace daemon na kailangang magsimula at mag-bootstrap pagkatapos ng bawat reboot bago ka makapag-log in. Pagplanuhan ito bago mo isara ang port, dahil ang failure mode dito ay mawalan ka ng access sa machine na hindi mo pisikal na mararating.

Magkaroon muna ng paraan para makabalik bago gumawa ng anumang pagbabago

Huwag magsimula hangga't wala kang recovery path na hindi gumagamit ng SSH.

Buksan ngayon ang console ng provider mo—ang VNC o serial console sa control panel—at mag-log in gamit ito. Kung hindi alam ang root password, i-reset muna ang root password mula sa panel at tiyaking gumagana ito. Ang console na hindi mo pa nasusubukan ay hindi recovery path.

Mahalaga ang pagkakasunod-sunod sa ibaba. Tinitiyak munang gumagana ang bawat hakbang bago patakbuhin ang kasunod, at mananatiling bukas ang port 22 hanggang gumana ang onion route.

1. I-install ang tor at tiyaking nakakapag-bootstrap ito.
2. I-define ang onion service at basahin ang address nito.
3. Kumonekta gamit ang onion habang bukas pa ang port 22.
4. Magdagdag ng client authorisation, pagkatapos ay kumonekta muli.
5. I-bind ang sshd sa loopback at isara ang port 22.
6. Mag-reboot, pagkatapos ay kumonekta muli gamit ang onion.

Panatilihing bukas ang kasalukuyan mong SSH session sa buong proseso. Mananatiling gumagana ang naitatag nang session kahit may firewall change na hahadlang sa bagong koneksyon, kaya ito ang una mong paraan ng pagsagip.

I-install ang tor sa server

Kasama ang tor sa sariling repository ng Ubuntu, ngunit madalas na luma ang build na iyon. Nasa repository ng Tor Project ang bersyong inilalarawan sa dokumentasyon nito. Idagdag ito gamit ang mga command mula sa apt repository guide.

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

Isulat ang /etc/apt/sources.list.d/tor.sources. Ginagamit ng Suites ang release codename mo, na ipinapakita ng lsb_release -cs (noble sa 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

Dapat magtapos ang log sa Bootstrapped 100% (done). Kung nananatili ito bago ang bahaging iyon, hindi maabot ng tor ang network. Halos palaging outbound firewall rule o lubhang maling oras ng system ang sanhi.

Bitag ang pangalan ng unit. Iniuulat ng systemctl status tor ang Active: active (exited) kahit maayos ang lahat, dahil bina-package ng Debian at Ubuntu ang tor bilang multi-instance master unit na ang tanging gawain ay i-load ang aktuwal na instance. Tumatakbo ang daemon mismo bilang tor@default.service. Gamitin ang pangalang iyon para sa status at journalctl. Umaabot pa rin sa instance ang start, stop, at reload ng tor, kaya gumagana ang sudo systemctl reload tor gaya ng inaasahan.

Itakda ang onion service para sa port 22

Magdagdag ng dalawang linya sa /etc/tor/torrc.

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

Sinasabi ng ikalawang linya sa tor na tumanggap ng virtual port 22 sa onion address at kumonekta sa 127.0.0.1:22 sa server. Inaabot ng tor ang sshd sa pamamagitan ng loopback. Ito mismo ang dahilan kung bakit maaaring ihinto ng sshd ang pakikinig sa public address. Ituro ang ikalawang linyang iyon sa isang web server sa 127.0.0.1:80, at pareho ring directive ang mag-publish ng site sa isang onion address, na isang kapaki-pakinabang na ikalawang service kapag naka-install na ang tor.

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

Nagpi-print ito ng 56 base32 character na sinusundan ng .onion. Ang mga character na iyon ang public key ng service sa naka-encode na anyo. Walang certificate authority at walang name registration na kailangan dito.

Hayaan ang tor na gumawa mismo ng /var/lib/tor/ssh/. Kung ikaw mismo ang gagawa nito gamit ang maling owner o mode na mas maluwag kaysa 0700, tatanggi ang tor na gamitin ito, at iuulat ng journal na masyadong permissive ang directory. Ang mga file sa loob nito ang identity ng service: ang hs_ed25519_secret_key ang address. I-back up ang directory na iyon gamit ang mode 600 at itago ang kopya sa labas ng server, dahil kapag nawala ito, magkakaroon ng bagong address at kailangang mag-edit ng config sa bawat client.

Kumonekta mula sa iyong workstation

Kailangan ng iyong workstation ng tor client, na hindi nangangailangan ng anumang configuration. Sa Debian o Ubuntu, ito ay sudo apt install -y tor netcat-openbsd. Pagkatapos, nakikinig ang Tor sa 127.0.0.1:9050 bilang SOCKS5 proxy. Ang SOCKS ay generic na proxy protocol, at maaaring magdala ang version 5 ng hostname sa halip na IP address. Ito ang mahalaga rito.

Walang sariling SOCKS client ang OpenSSH, kaya kailangan ng helper program para sa koneksyon. Idagdag ito sa ~/.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

Pinipili ng -X 5 ang SOCKS5, at itinuturo ng -x 127.0.0.1:9050 ang local tor. Ipinapasa ng %h ang onion name sa tor bilang pangalan, kaya sa loob ng network ito nire-resolve ng tor. Dapat itong OpenBSD netcat. Walang -X option ang GNU netcat at humihinto ito na may nc: invalid option -- 'X'.

ssh myvps

Mabagal ang unang koneksyon dahil bumubuo muna ang tor ng circuit bago mangyari ang iba pa. Tanggapin ang host key fingerprint gaya ng karaniwan mong ginagawa. Mula rito, hindi nagbabago ang karaniwang paghawak sa SSH key. Nagbago ang transport. Hindi nagbago ang authentication.

Para sa isang beses na koneksyon, maaari mong laktawan ang config entry: Pareho ang ginagawa ng torsocks ssh admin@xxxxx.onion.

Magdagdag ng v3 client authorisation

Sa kasalukuyan, maaabot ng sinumang nakakaalam ng address ang iyong SSH banner at maaari silang magsimulang manghula. Hindi maaaring i-enumerate ang mga Onion address mula sa directory system, kaya gumaganap ang address bilang secret, pero maaari itong ma-leak sa karaniwang paraan: sa shell history at sa mga config file na na-commit sa isang git repository. Tinatakpan ng client authorisation ang puwang na ito. Ini-encrypt ng service ang descriptor nito gamit ang client key, kaya hindi man lang mahanap ng sinumang may address pero walang key ang service.

Bumuo ng x25519 key pair sa client. Ito ang pipeline mula sa client authorisation guide ng Tor Project, na may isang pagbabago.

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

Ginagamit ng inilabas na bersyon ng mga linyang iyon ang base64pem -d, na wala sa karaniwang Ubuntu install. Hihinto ang command na may base64pem: command not found. Parehong dine-decode ng GNU base64 -d ang PEM body, kaya iyon ang gamitin.

Sa server, i-install ang public key.

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

Mga file lamang na nagtatapos sa .auth ang binabasa. I-save ito bilang laptop.auth.txt. I-i-ignore ng tor ang file kapag walang ganitong suffix at walang error na ipi-print, kaya tahimik na mananatiling bukas ang service sa sinumang may address.

Sa client, i-install ang private key. Sa Ubuntu, tumatakbo ang tor daemon bilang user na debian-tor at hindi nito mababasa ang mga file sa iyong home directory, kaya ilagay ang directory sa lokasyong maaabot ng user na iyon.

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

Idagdag ang ClientOnionAuthDir /var/lib/tor/onion_auth sa /etc/tor/torrc ng client at i-reload ang tor. Kung pinapatakbo mo ang tor bilang sarili mong user, gaya ng Homebrew build sa macOS, ituro ang ClientOnionAuthDir sa ~/.tor/onion_auth na may mode 0700.

Ang address sa loob ng file na iyon ay ang 56 characters na walang suffix na .onion. Tanggalin ang /tmp/k1.prv.pem at /tmp/k1.prv.key kapag tapos ka na.

Subukan ngayon ang parehong direksiyon. Dapat kumonekta pa rin ang ssh myvps. Mula sa machine na walang hawak na key, dapat mabigo ang pagkonekta gamit ang parehong address. Ang kabiguang iyon ang patunay na aktibo ang authorisation.

Isara ang port 22, sa ganitong pagkakasunod-sunod

Magtakda muna ng safety net. Binabawi ng command na ito ang dalawang pagbabagong nasa ibaba pagkalipas ng fifteen minutes kung ma-lock out ka.

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'

Kanselahin ito gamit ang sudo systemctl stop ssh-rescue.timer kapag nakumpirma mong gumagana pa rin ang onion route.

Sunod, itigil ang pakikinig ng sshd sa public address. Sa Ubuntu 24.04, ina-activate ang SSH sa pamamagitan ng socket unit, kaya binabalewala ang ListenAddress sa sshd_config: ang ssh.socket ang may-ari ng listening socket, hindi ang sshd. Suriin kung alin sa dalawang sitwasyon ang gamit mo.

systemctl is-enabled ssh.socket

Kung enabled ang output, patakbuhin ang sudo systemctl edit ssh.socket at idagdag ito.

[Socket]
ListenStream=
ListenStream=127.0.0.1:22

Nililinis ng walang laman na ListenStream= ang value na minana mula sa packaged unit. Kung aalisin mo ang linyang iyon, magdadagdag ka ng pangalawang listener habang nananatili ang public one. Ito ang pinakakaraniwang dahilan kung bakit tahimik na nabibigo ang hakbang na ito.

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

Dapat ipakita ng ss ang 127.0.0.1:22 at walang anuman sa 0.0.0.0:22. Kung disabled ang ssh.socket, ilagay ang ListenAddress 127.0.0.1 sa /etc/ssh/sshd_config.d/10-onion.conf, patakbuhin ang sudo systemctl restart ssh, at pagkatapos ay suriin gamit ang parehong linyang ss. Ang output na iyon ang patunay sa alinmang sitwasyon.

Pagkatapos, ang firewall. Karaniwang pamamahala ito ng ufw rule sa isang VPS. Patakbuhin muna ang sudo ufw status numbered at burahin ang SSH rule na ililista nito.

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

Panatilihing pinapayagan ang outbound traffic. Kumokonekta ang Tor palabas sa mga relay sa mga port gaya ng 443 at 9001, kaya pinipigilan ng outbound default-deny policy ang pag-bootstrap ng Tor at inaalis nito ang natitira mong paraan para makapasok sa parehong oras. Karamihan sa mga provider ay nagpapatakbo rin ng hiwalay na network firewall sa control panel. Isara rin ang 22 doon, kung hindi ay mananatiling reachable ang port anuman ang i-report ng ufw.

Kung tumatakbo ang Docker sa server na ito, suriin ang mga published port nito bago mo ituring na tapos ang gawain. Isinusulat ng Docker ang sarili nitong rules sa parehong tables at direktang nagpa-publish ng container ports lampas sa ufw, kaya hindi kumpleto ang larawan kapag ufw deny policy lamang ang sinuri.

Mag-reboot bago ito pagkatiwalaan

systemctl is-enabled tor@default
sudo reboot

Kung hindi nag-ulat ang unang command na enabled ang service, patakbuhin ang sudo systemctl enable tor@default bago mag-reboot. Maghintay ng dalawang minuto, pagkatapos ay ssh myvps. Kailangang mag-bootstrap ang Tor pagkatapos ng boot, kaya magsisimulang sumagot ang onion address ilang sandali matapos umandar ang mismong machine.

Kung hindi ito muling gumana, buksan ang console at basahin ang sudo journalctl -u tor@default -b. Ipinapakita roon ang syntax error sa torrc o problema sa permission ng directory. Maaari mo ring i-check ang isang pagbabago sa torrc bago ito i-apply.

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

Ano ang gastos nito kumpara sa WireGuard tunnel

Kung ihahambing sa WireGuard VPN sa sarili mong VPS, mas mabagal at mas hindi predictable ang onion service. Maging tapat sa pagtatasa ng trade-off bago mo ito gamitin.

Latency. Tatlong relay ang nasa client circuit, at nagdadagdag pa ng tatlo ang service side. Kaya dumadaan ang bawat keystroke sa humigit-kumulang anim na machine na random na pinili sa iba’t ibang bahagi ng mundo. Kapansin-pansin ang delay kapag nagta-type nang interactive, at mabagal ang pagkopya ng mga file. Isang hop lang ang idinadagdag ng WireGuard. Sukatin ang sarili mong kaso gamit ang time ssh myvps 'echo ok', dahil nakadepende ang resulta sa circuit na nabuo ng tor at nagbabago ito kapag bumuo ang tor ng panibagong circuit.

Userspace daemon sa critical path. Nasa kernel ang WireGuard at awtomatikong umaandar kasabay ng network. Ang Tor ay isang process na kailangang mag-start, mag-bootstrap, at makakonekta sa isang guard relay bago gumana ang anuman. Kapag nag-fail ito, kailangan mong gumamit ng provider console.

Accuracy ng oras. Pino-publish ang mga onion service descriptor batay sa mga time period. Kaya kapag malaki ang mali ng system clock, masisira ang address lookup nang walang malinaw na mensahe saanman. Dapat i-report ng timedatectl ang System clock synchronized: yes.

Ang kapalit nito ay mas kaunting exposure na hindi na nakadepende sa tamang pag-configure ng firewall rule. Walang port na maaaring i-scan at walang banner na maaaring kunin. Public key mismo ang address, kaya napapatunayan ng endpoint ang identity nito bago pa magsimula ang SSH.

Karaniwan, parehong ginagamit ang dalawang ito. Gamitin ang WireGuard bilang pang-araw-araw na path, at panatilihin ang onion service bilang route na gumagana pa rin kapag mali ang WireGuard config. Sa ganitong setup, isang UDP port lang ang nakabukas sa halip na public SSH port. Hindi nito pinapalitan ang pag-hardening mismo sa sshd: mahalaga pa rin ang key-only authentication at non-root login, dahil pinoprotektahan lamang ng onion service ang network path at wala nang iba pa.

Mga failure mode at mga error na makikita mo

Hindi kailanman lumalagpas ang Tor sa Bootstrapped 0%. Naka-block ang outbound traffic, o mali nang malaki ang oras ng system. Suriin ang outgoing policy gamit ang sudo ufw status verbose, saka patakbuhin ang timedatectl.

Sinasabi ng systemctl status tor ang active (exited). Normal ito sa Debian at Ubuntu. Sa halip, basahin ang tor@default.

Hindi makita ang descriptor. Ibinabalik ng Tor ang SOCKS extended error F0, "Hindi makita ang Onion Service Descriptor". Maaaring hindi pa na-publish ang descriptor, na karaniwang tumatagal nang kaunti matapos ang reload, o hindi tumatakbo ang tor sa server.

F4, "Walang Client Authorization ang Onion Service". Walang katugmang .auth_private ang client na magagamit ng tor. Tiyaking nasa torrc ang ClientOnionAuthDir, mode 0700 ang directory, nagtatapos sa .auth_private ang filename, at nababasa ito ng debian-tor.

F5, "Maling Client Authorization ang Onion Service". Hindi tumutugma ang private key sa .auth file sa server. Nagdudulot nito ang trailing = o stray newline sa loob ng base32 string.

nc: invalid option -- 'X'. GNU netcat ang naka-install sa halip na OpenBSD netcat. Patakbuhin ang sudo apt install -y netcat-openbsd.

Could not resolve hostname. Gumamit ang ssh ng ordinaryong DNS, na walang sagot para sa .onion, kaya hindi kailanman tumakbo ang ProxyCommand. Hindi tumutugma ang Host pattern sa ~/.ssh/config sa pangalang inilagay mo.

Permission denied (publickey). Gumana ang tunnel at tapos na ang tor. Ituring ito bilang karaniwang permission denied publickey problem at huwag isama ang tor sa pag-troubleshoot.

FAQ

Totoo bang walang bukas na port sa aking VPS kapag gumagamit ng onion service?

Oo, kapag naka-bind ang sshd sa 127.0.0.1 at nagda-drop ang firewall ng inbound traffic. Gumagawa ang Tor ng outbound TCP connection papunta sa isang relay, at dumadaan pabalik dito ang session mo. Dahil dito, walang tumatanggap ng connection sa public address sa server. Patunayan ito gamit ang ss -tlnp sa server at magpatakbo ng port scan mula sa ibang lugar. Huwag kalimutan ang sariling network firewall ng provider sa control panel. Hiwalay ito sa ufw at kailangan ding isara ang mga inbound connection doon.

Sapat na bang seguridad ang .onion address para sa SSH?

Hindi. 56 characters ang address at hindi ito maaaring hulaan o i-enumerate mula sa directory system, kaya kumikilos itong parang secret. Gayunman, maaaring ma-leak ito sa shell history at config files. Magdagdag ng v3 client authorisation. Kapag naka-enable ito, ine-encrypt ang service descriptor gamit ang client key mo. Kaya ang sinumang address lang ang hawak ay makakatanggap ng extended error F4 at hindi kailanman makakarating sa sshd.

Ano ang mangyayari kung hindi magsimulang muli ang tor pagkatapos ng reboot?

Mawawala nang tuluyan ang SSH access dahil ang onion address na lamang ang paraan para makapasok. Kaya kailangang subukan ang provider console bago mo isara ang port 22. Kailangan din ng Tor ng oras para mag-bootstrap pagkatapos ng boot. Dahil dito, mas huli itong sumasagot kaysa sa machine kapag nag-ping. Kung hindi ito kailanman sumagot, mag-login sa console at basahin ang sudo journalctl -u tor@default -b. Doon makikita ang torrc syntax error o permission problem sa /var/lib/tor/ssh.

Mas mabagal ba ang SSH over Tor kaysa sa WireGuard?

Oo, malaki ang diperensiya. Dumadaan ang connection sa onion service sa humigit-kumulang anim na relay na random na pinipili. Samantala, isang encrypted hop lang ang WireGuard diretso sa server mo. Mabagal ang pakiramdam kapag nagta-type at mabagal ang mga transfer. Karaniwang setup ang WireGuard para sa pang-araw-araw na trabaho, habang pinananatili ang onion service bilang emergency route na gumagana kahit may sirang VPN config.