SSH sa Tor onion service nang walang open ports

Mga pagbabago kapag SSH sa pamamagitan ng Tor onion service

Sa pamamagitan ng SSH sa Tor onion service, maaari mong i-administer ang VPS na walang tumatanggap na inbound connection sa anumang port. Ang server ang kumokonekta palabas sa Tor network at pinananatiling bukas ang connection na iyon. Dito dumadaan pabalik ang iyong SSH session, kaya walang kailangang mag-listen sa public IP address.

Agad makikita ang epekto sa log. Ang server na may public SSH port ay nakatatanggap ng libo-libong bigong pagtatangka sa 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-login. Planuhin ito bago mo isara ang port, dahil ang failure mode dito ay mawalan ng access sa machine na hindi mo pisikal na maaabot.

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 iyong provider—ang VNC o serial console sa control panel—at mag-login 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 maituturing na recovery path.

Mahalaga ang pagkakasunod-sunod sa ibaba. Tinitiyak muna na 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 nakumpleto nito ang bootstrap.
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 aktibo ang isang naitatag nang session kahit may firewall change na haharang sa bagong koneksyon, kaya ito ang una mong rescue path.

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 kanilang documentation. Idagdag ito gamit ang mga command mula sa kanilang 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. Kinukuha 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). Kapag nananatili ito sa naunang bahagi, hindi maabot ng tor ang network. Halos palagi itong sanhi ng outbound firewall rule o ng maling-maling oras ng system.

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 tungkulin 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 ayon sa inaasahan.

Tukuyin 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 ang dahilan kung bakit maaaring ihinto ng sshd ang pakikinig sa public address sa susunod.

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 encoded form ng public key ng service. 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, kailangan ng bagong address at pagbabago sa config ng bawat client.

Kumonekta mula sa iyong workstation

Kailangan ng iyong workstation ng tor client, na walang kailangang configuration. Sa Debian o Ubuntu, ito ay sudo apt install -y tor netcat-openbsd. Nakikinig ang Tor sa 127.0.0.1:9050 bilang SOCKS5 proxy. Isang generic proxy protocol ang SOCKS, 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 maisagawa ang connection. 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 sa lokal na tor. Ipinapasa ng %h ang onion name sa tor bilang pangalan, kaya nireresolba ito ng tor sa loob ng network. Dapat itong OpenBSD netcat. Walang -X option ang GNU netcat at humihinto ito sa nc: invalid option -- 'X'.

ssh myvps

Mabagal ang unang connection dahil bumubuo muna ang tor ng circuit bago magsimula ang iba pa. Tanggapin ang host key fingerprint gaya ng karaniwang ginagawa sa ibang connection. Mula rito, hindi nagbabago ang karaniwang pag-handle ng SSH key. Nagbago ang transport. Hindi nagbago ang authentication.

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

Magdagdag ng v3 client authorisation

Sa kasalukuyan, maaaring maabot ng sinumang nakakaalam ng address ang iyong SSH banner at magsimulang manghula. Hindi maaaring i-enumerate ang mga onion address mula sa directory system, kaya kumikilos ang address na parang secret. Gayunman, maaaring kumalat ito sa karaniwang paraan, gaya ng shell history at mga config file na na-commit sa isang git repository. Isinasara ng client authorisation ang puwang na ito. Ine-encrypt ng service ang descriptor nito gamit ang client key. Dahil dito, hindi mahanap ng sinumang may address pero walang key ang service.

Mag-generate 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 inilathalang bersyon ng mga linyang iyon ang base64pem -d, na wala sa karaniwang Ubuntu install. Ihihinto ng command ang execution sa base64pem: command not found. Ide-decode ng GNU base64 -d ang parehong 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

Ang mga file lamang na nagtatapos sa .auth ang binabasa. I-save ito bilang laptop.auth.txt. Kapag walang ganoong pangalan ang file, hindi ito babasahin ng tor at walang error na ipi-print. Mananatiling bukas nang tahimik 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 nakakonekta pa rin ang ssh myvps. Mula sa machine na walang hawak na key, dapat mabigo ang parehong address. Ang pagkabigong 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 pagbabago sa ibaba pagkalipas ng labinlimang minuto 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, ihinto 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 ang gamit mo.

systemctl is-enabled ssh.socket

Kung mag-print ito ng enabled, 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 second listener habang pinananatili 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 ss line. Ang output na iyon ang patunay sa alinmang kaso.

Pagkatapos, i-configure ang firewall. Karaniwan itong pamamahala ng ufw rules sa isang VPS. Patakbuhin muna ang sudo ufw status numbered at tanggalin 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 naka-allow ang outgoing traffic. Kumokonekta ang Tor palabas sa mga relay gamit ang mga port gaya ng 443 at 9001, kaya pinipigilan ng outbound default-deny policy ang Tor na mag-bootstrap at sabay nitong inaalis ang natitira mong paraan para makapasok. Karamihan sa mga provider ay nagpapatakbo rin ng hiwalay na network firewall sa control panel. Isara rin ang port 22 doon; kung hindi, 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 trabaho. 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 kung ufw deny policy lamang ang susuriin.

Mag-reboot bago ito pagkatiwalaan

systemctl is-enabled tor@default
sudo reboot

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

Kung hindi na ito muling bumalik, 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 ilapat.

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

Ano ang kapalit 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 pagsusuri sa trade-off bago mo ito gamitin.

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

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

Katumpakan ng oras. Naka-publish ang onion service descriptors batay sa mga time period. Kaya kapag mali nang malaki ang system clock, hindi gagana ang address lookup at walang malinaw na mensahe kung saan man. Dapat i-report ng timedatectl ang System clock synchronized: yes.

Ang kapalit nito ay mas kaunting exposure na hindi na nakadepende sa tamang pagkaka-configure ng firewall rule. Walang port na maaaring i-scan at walang banner na maaaring makuha. 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 gagana pa rin kapag mali ang WireGuard config. Isang UDP port lang ang kailangang bukas sa halip na public SSH port. Hindi nito pinapalitan ang pag-hardening sa sshd mismo: 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 nalalagpasan ng Tor ang Bootstrapped 0%. Naka-block ang outbound traffic, o sobrang layo ng oras ng system. Suriin ang outgoing policy gamit ang sudo ufw status verbose, pagkatapos ay 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, "Onion Service Descriptor Can Not be Found". Maaaring hindi pa nailalathala ang descriptor, na karaniwang tumatagal nang kaunti pagkatapos ng reload, o hindi tumatakbo ang tor sa server.

F4, "Onion Service Missing Client Authorization". 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 mababasa ito ng debian-tor.

F5, "Onion Service Wrong Client Authorization". Hindi tumutugma ang private key sa .auth file sa server. Nagiging sanhi nito ang trailing = o sobrang 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. Sinubukan ng ssh ang ordinary 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 ordinaryong permission denied publickey problem at huwag isama ang tor sa pagsusuri.

FAQ

Talaga bang nangangahulugang walang open port sa aking VPS ang isang onion service?

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

Sapat na bang security 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. Pero maaaring ma-leak ito sa shell history at config files. Magdagdag ng v3 client authorisation. Sa pamamagitan nito, naka-encrypt ang service descriptor gamit ang client key mo. Kaya ang sinumang address lang ang hawak ay makakakuha ng extended error F4 at hindi kailanman makakarating sa sshd.

Ano ang mangyayari kung hindi magsimula ang tor pagkatapos ng reboot?

Mawawala nang tuluyan ang SSH access dahil ang onion address na lang ang natitirang paraan para makapasok. Kaya kailangang subukan muna 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 sumasagot ang address 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 naka-print ang torrc syntax error o permissions problem sa /var/lib/tor/ssh.

Mas mabagal ba ang SSH sa Tor kaysa sa WireGuard?

Oo, malaki ang diperensiya. Dumadaan ang connection sa onion service sa humigit-kumulang anim na relay na random na pinipili, samantalang isang encrypted hop lang ang WireGuard diretso sa server mo. Ramdam ang lag 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 masira ang VPN config.