วิธีตั้งค่า SSH ผ่าน Tor onion service ไม่ต้องเปิดพอร์ต

สิ่งที่เปลี่ยนไปเมื่อใช้ SSH ผ่าน Tor onion service

การใช้งาน SSH ผ่าน Tor onion service ช่วยให้คุณสามารถดูแล VPS ที่ไม่เปิดรับการเชื่อมต่อขาเข้าผ่านพอร์ตใดๆ ได้ โดยเซิร์ฟเวอร์จะทำการเชื่อมต่อไปยังเครือข่าย Tor และคงการเชื่อมต่อนั้นไว้ เซสชัน SSH ของคุณจะถูกส่งผ่านช่องทางนี้กลับมา ทำให้ไม่มีบริการใดต้องเปิดพอร์ตค้างไว้บน public IP address

ผลลัพธ์ที่ปรากฏใน log จะเปลี่ยนไปทันที เซิร์ฟเวอร์ที่เปิดพอร์ต SSH สาธารณะมักจะถูกสแกนและพบความพยายามเดารหัสผ่านนับพันครั้งต่อวัน หากคุณย้าย sshd ไปไว้หลัง onion service และปิดกั้น traffic ขาเข้าที่ firewall แล้ว /var/log/auth.log จะบันทึกเฉพาะเซสชันที่คุณเป็นผู้เริ่มใช้งานเท่านั้น

ข้อควรระวังคือ tor จะเข้ามาเป็นตัวกลางในทุกเซสชันการดูแลระบบ มันเป็น daemon ในระดับ userspace ที่ต้องเริ่มทำงานและ bootstrap หลังจากรีบูตทุกครั้งก่อนที่คุณจะล็อกอินได้ โปรดวางแผนในส่วนนี้ให้ดีก่อนปิดพอร์ต เพราะหากเกิดความผิดพลาด คุณอาจสูญเสียการเข้าถึงเครื่องที่ไม่สามารถเข้าถึงทางกายภาพได้

เตรียมช่องทางกู้คืนระบบก่อนเริ่มดำเนินการใดๆ

ห้ามเริ่มดำเนินการจนกว่าคุณจะมีช่องทางกู้คืนระบบที่ไม่ต้องพึ่งพา SSH

ให้เปิดคอนโซลของผู้ให้บริการของคุณผ่านทาง VNC หรือ serial console ในแผงควบคุม แล้วเข้าสู่ระบบผ่านช่องทางนั้น หากไม่ทราบรหัสผ่าน root ให้ รีเซ็ตรหัสผ่าน root จากแผงควบคุม ก่อนและตรวจสอบให้แน่ใจว่าใช้งานได้จริง คอนโซลที่คุณไม่เคยทดสอบใช้งานมาก่อนไม่ถือว่าเป็นช่องทางกู้คืนระบบ

ลำดับขั้นตอนด้านล่างนี้มีความสำคัญ ทุกขั้นตอนได้รับการพิสูจน์แล้วว่าใช้งานได้ก่อนที่จะดำเนินการในขั้นตอนถัดไป และพอร์ต 22 จะยังคงเปิดอยู่จนกว่าการเชื่อมต่อผ่าน onion จะทำงานได้สำเร็จ

1. ติดตั้ง tor และตรวจสอบว่าระบบสามารถ bootstrap ได้สำเร็จ
2. กำหนดค่า onion service และอ่านที่อยู่ (address) ของบริการ
3. เชื่อมต่อผ่าน onion ในขณะที่พอร์ต 22 ยังคงเปิดอยู่
4. เพิ่มการยืนยันตัวตนของไคลเอนต์ (client authorisation) จากนั้นทดสอบเชื่อมต่ออีกครั้ง
5. ผูก sshd ไว้กับ loopback และปิดพอร์ต 22
6. รีบูตระบบ จากนั้นเชื่อมต่อผ่าน onion อีกครั้ง

ให้เปิดเซสชัน SSH ปัจจุบันของคุณทิ้งไว้ตลอดกระบวนการ เซสชันที่เชื่อมต่ออยู่แล้วจะยังคงทำงานได้แม้มีการเปลี่ยนแปลงไฟร์วอลล์ที่อาจบล็อกการเชื่อมต่อใหม่ ดังนั้นนี่จึงเป็นแนวทางกู้คืนระบบด่านแรกของคุณ

การติดตั้ง tor บนเซิร์ฟเวอร์

Ubuntu มีแพ็กเกจ tor ใน repository ของตนเอง แต่เวอร์ชันดังกล่าวมักจะล้าสมัยกว่าเวอร์ชันที่ระบุไว้ในเอกสารประกอบของ The Tor Project ให้เพิ่ม repository ของโครงการโดยใช้คำสั่งจาก คู่มือ apt repository

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 ซึ่งจะระบุ codename ของรุ่นที่คุณใช้งานอยู่ (เช่น noble บน Ubuntu 24.04) ซึ่งสามารถตรวจสอบได้ด้วยคำสั่ง lsb_release -cs

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 ไม่สามารถเชื่อมต่อเครือข่ายได้ ซึ่งมักเกิดจากกฎของ outbound firewall หรือการตั้งค่าเวลาของระบบที่ไม่ถูกต้อง

ชื่อ unit เป็นสิ่งที่ควรระวัง systemctl status tor จะรายงานสถานะเป็น Active: active (exited) แม้ว่าระบบจะทำงานปกติ ทั้งนี้เพราะ Debian และ Ubuntu จัดแพ็กเกจ tor ในรูปแบบ multi-instance master unit ซึ่งมีหน้าที่เพียงเรียกใช้งาน instance จริงเท่านั้น ตัว daemon จะทำงานในชื่อ tor@default.service ให้ใช้ชื่อนี้สำหรับ status และ journalctl อย่างไรก็ตาม คำสั่ง start, stop และ reload ของ tor ยังคงส่งผลต่อ instance หลัก ดังนั้น sudo systemctl reload tor จึงทำงานได้ตามที่คุณคาดหวัง

กำหนดค่า onion service สำหรับพอร์ต 22

เพิ่มสองบรรทัดลงใน /etc/tor/torrc

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

บรรทัดที่สองสั่งให้ tor ยอมรับ virtual port 22 บน onion address และเชื่อมต่อไปยัง 127.0.0.1:22 บนเครื่องนี้ Tor จะเข้าถึง sshd ผ่าน loopback ซึ่งเป็นเหตุผลว่าทำไม sshd ถึงสามารถหยุดฟังการเชื่อมต่อบน public address ได้ในภายหลัง หากคุณเปลี่ยนบรรทัดที่สองให้ชี้ไปยังเว็บเซิร์ฟเวอร์บน 127.0.0.1:80 แทน ก็จะเป็นการใช้คำสั่งสองบรรทัดเดียวกันนี้เพื่อ เผยแพร่เว็บไซต์บน onion address ซึ่งเป็นบริการที่มีประโยชน์อีกอย่างหนึ่งที่สามารถรันได้หลังจากติดตั้ง tor แล้ว

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

คำสั่งดังกล่าวจะแสดงอักขระ base32 จำนวน 56 ตัว ตามด้วย .onion อักขระเหล่านี้คือ public key ของบริการในรูปแบบที่ถูกเข้ารหัสไว้ โดยไม่มีหน่วยงานออกใบรับรอง (certificate authority) และไม่มีการลงทะเบียนชื่อใดๆ ทั้งสิ้นในกระบวนการนี้

ปล่อยให้ tor สร้าง /var/lib/tor/ssh/ ขึ้นมาเอง หากคุณสร้างขึ้นมาด้วยตนเองโดยกำหนดเจ้าของไม่ถูกต้อง หรือกำหนดโหมดที่หละหลวมกว่า 0700 tor จะปฏิเสธการใช้งาน และบันทึกใน journal จะรายงานว่าไดเรกทอรีดังกล่าวมีสิทธิ์เข้าถึงที่กว้างเกินไป ไฟล์ที่อยู่ภายในคือตัวตนของบริการ โดย hs_ed25519_secret_key คือ ที่อยู่ของบริการนั้น ให้สำรองข้อมูลไดเรกทอรีดังกล่าวด้วยโหมด 600 และเก็บสำเนาไว้นอกเครื่อง เพราะหากทำไฟล์นี้หาย จะหมายถึงการต้องเปลี่ยนที่อยู่ใหม่และต้องแก้ไขการตั้งค่าบนไคลเอนต์ทุกเครื่อง

การเชื่อมต่อจากเวิร์กสเตชันของคุณ

เวิร์กสเตชันของคุณจำเป็นต้องมี tor client ซึ่งไม่จำเป็นต้องตั้งค่าใดๆ เพิ่มเติม สำหรับ Debian หรือ Ubuntu ให้ใช้ sudo apt install -y tor netcat-openbsd จากนั้น Tor จะเปิดฟังที่ 127.0.0.1:9050 ในฐานะ SOCKS5 proxy โดย SOCKS เป็นโปรโตคอลพร็อกซีทั่วไป และเวอร์ชัน 5 สามารถส่งชื่อโฮสต์แทนที่หมายเลข IP ได้ ซึ่งเป็นส่วนสำคัญในกรณีนี้

OpenSSH ไม่มี SOCKS client ในตัว จึงต้องใช้โปรแกรมช่วยในการเชื่อมต่อ ให้เพิ่มข้อความต่อไปนี้ลงใน ~/.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 ไปให้ tor เพื่อให้ tor ทำการ resolve ชื่อภายในเครือข่าย ทั้งนี้ต้องใช้ OpenBSD netcat เท่านั้น เนื่องจาก GNU netcat ไม่มีออปชัน -X และจะหยุดทำงานพร้อมกับ nc: invalid option -- 'X'

ssh myvps

การเชื่อมต่อครั้งแรกจะช้าเนื่องจาก tor ต้องสร้างวงจร (circuit) ก่อนที่จะดำเนินการอื่นใด ให้ยอมรับ host key fingerprint เช่นเดียวกับที่คุณทำในกรณีปกติ หลังจากจุดนี้เป็นต้นไป การจัดการ SSH key ตามปกติ จะมีผลบังคับใช้โดยไม่มีการเปลี่ยนแปลงใดๆ เนื่องจากเป็นการย้ายเพียงช่องทางการขนส่งข้อมูลเท่านั้น แต่ไม่ได้เปลี่ยนวิธีการยืนยันตัวตน

สำหรับการใช้งานเพียงครั้งเดียว คุณสามารถข้ามการตั้งค่าในไฟล์ config ได้ โดยใช้คำสั่ง torsocks ssh admin@xxxxx.onion ซึ่งให้ผลลัพธ์เช่นเดียวกัน

การเพิ่มการยืนยันตัวตนไคลเอนต์ v3

ในสถานะปัจจุบัน ใครก็ตามที่ทราบที่อยู่จะสามารถเข้าถึง SSH banner ของคุณและเริ่มเดารหัสผ่านได้ ที่อยู่ Onion ไม่สามารถถูกแจกแจงจากระบบ directory ได้ ดังนั้นที่อยู่จึงทำหน้าที่เสมือนความลับ แต่ที่อยู่เหล่านี้อาจรั่วไหลได้ในช่องทางปกติ เช่น ประวัติการใช้งาน shell และไฟล์ config ที่ถูก commit ลงใน git repository การยืนยันตัวตนไคลเอนต์ (client authorisation) จะช่วยปิดช่องโหว่นี้ บริการจะเผยแพร่ descriptor ที่เข้ารหัสไว้ด้วยกุญแจของไคลเอนต์ ดังนั้นผู้ที่มีเพียงที่อยู่แต่ไม่มีกุญแจจะไม่สามารถระบุตำแหน่งของบริการได้

สร้างคู่กุญแจ x25519 บนฝั่งไคลเอนต์ นี่คือขั้นตอนจาก คู่มือการยืนยันตัวตนไคลเอนต์ ของ Tor Project โดยมีการปรับเปลี่ยนหนึ่งจุด

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 ซึ่งการติดตั้ง Ubuntu แบบมาตรฐานไม่มีมาให้ คำสั่งจึงหยุดทำงานพร้อมกับ base64pem: command not found โดย GNU base64 -d สามารถถอดรหัสเนื้อหา PEM เดียวกันได้ จึงให้ใช้คำสั่งนี้แทน

บนฝั่งเซิร์ฟเวอร์ ให้ติดตั้งกุญแจ สาธารณะ (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

ระบบจะอ่านเฉพาะไฟล์ที่ลงท้ายด้วย .auth เท่านั้น หากคุณบันทึกเป็น laptop.auth.txt ตัว tor จะเพิกเฉยต่อไฟล์นั้นโดยไม่แสดงข้อผิดพลาดใดๆ และบริการจะยังคงเปิดรับทุกคนที่มีที่อยู่อย่างเงียบเชียบ

บนฝั่งไคลเอนต์ ให้ติดตั้งกุญแจ ส่วนตัว (private key) บน Ubuntu นั้น tor daemon จะทำงานในฐานะผู้ใช้ debian-tor และไม่สามารถอ่านไฟล์ในไดเรกทอรี home ของคุณได้ ดังนั้นควรเก็บไดเรกทอรีไว้ในที่ที่ผู้ใช้ดังกล่าวสามารถเข้าถึงได้

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

เพิ่ม ClientOnionAuthDir /var/lib/tor/onion_auth ลงในไฟล์ /etc/tor/torrc ของไคลเอนต์แล้วโหลด tor ใหม่ หากคุณรัน tor ในฐานะผู้ใช้ของคุณเอง เช่น การติดตั้งผ่าน Homebrew บน macOS ให้ชี้ ClientOnionAuthDir ไปที่ ~/.tor/onion_auth โดยกำหนดโหมดเป็น 0700

ที่อยู่ภายในไฟล์นั้นคืออักขระ 56 ตัว โดยไม่มี ส่วนต่อท้าย .onion ให้ลบ /tmp/k1.prv.pem และ /tmp/k1.prv.key ทิ้งเมื่อดำเนินการเสร็จสิ้น

จากนั้นทดสอบทั้งสองทิศทาง ssh myvps ควรจะยังคงเชื่อมต่อได้ตามปกติ ส่วนจากเครื่องที่ไม่มีกุญแจ ที่อยู่เดียวกันควรจะเชื่อมต่อไม่ได้ ความล้มเหลวในการเชื่อมต่อนั้นคือหลักฐานว่าการยืนยันตัวตนทำงานอยู่

ปิดพอร์ต 22 ตามลำดับนี้

กำหนดตาข่ายนิรภัยไว้ก่อน คำสั่งนี้จะยกเลิกการเปลี่ยนแปลงทั้งสองรายการด้านล่างโดยอัตโนมัติหลังจากผ่านไป 15 นาที หากคุณล็อกตัวเองออกจากระบบ

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'

ยกเลิกคำสั่งดังกล่าวด้วย sudo systemctl stop ssh-rescue.timer เมื่อคุณยืนยันแล้วว่าเส้นทาง onion ยังคงทำงานได้ตามปกติ

ถัดไป ให้หยุด sshd ไม่ให้ฟังคำสั่งบน public address สำหรับ Ubuntu 24.04 จะเปิดใช้งาน ssh ผ่าน socket unit ดังนั้น ListenAddress ใน sshd_config จะถูกละเว้น เนื่องจาก ssh.socket เป็นผู้ควบคุม socket ที่รอรับการเชื่อมต่อ ไม่ใช่ sshd ให้ตรวจสอบว่าระบบของคุณอยู่ในกรณีใด

systemctl is-enabled ssh.socket

หากคำสั่งดังกล่าวแสดงผลเป็น enabled ให้รัน sudo systemctl edit ssh.socket แล้วเพิ่มบรรทัดนี้เข้าไป

[Socket]
ListenStream=
ListenStream=127.0.0.1:22

การปล่อย ListenStream= ให้ว่างจะเป็นการล้างค่าที่สืบทอดมาจาก packaged unit หากคุณละเว้นบรรทัดนี้ คุณจะเพิ่ม listener ตัวที่สองเข้าไปในขณะที่ยังคงเปิดตัว public ไว้ ซึ่งเป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้ขั้นตอนนี้ล้มเหลวโดยไม่มีการแจ้งเตือน

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 ถูกปิดใช้งาน ให้ใส่ ListenAddress 127.0.0.1 ลงใน /etc/ssh/sshd_config.d/10-onion.conf จากนั้นรัน sudo systemctl restart ssh แล้วตรวจสอบอีกครั้งด้วยคำสั่ง ss บรรทัดเดิม ผลลัพธ์ที่ได้จะเป็นเครื่องยืนยันในทั้งสองกรณี

จากนั้นจัดการ firewall ซึ่งเป็นเรื่องปกติของการ จัดการกฎ ufw บน VPS ให้รัน sudo ufw status numbered ก่อนแล้วลบกฎ SSH รายการใดก็ตามที่แสดงอยู่ในรายการ

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 จะเชื่อมต่อออกไปยัง relay ผ่านพอร์ตต่างๆ เช่น 443 และ 9001 ดังนั้นนโยบาย default-deny สำหรับขาออกจะทำให้ tor ไม่สามารถเริ่มต้นระบบ (bootstrapping) ได้ และเป็นการตัดช่องทางเดียวที่คุณเหลืออยู่ในการเข้าถึงระบบไปพร้อมกัน ผู้ให้บริการส่วนใหญ่มักมี network firewall แยกต่างหากใน control panel ให้ปิดพอร์ต 22 ที่นั่นด้วย มิฉะนั้นพอร์ตจะยังคงเข้าถึงได้ไม่ว่า ufw จะรายงานอย่างไรก็ตาม

หากมีการรัน Docker บนเครื่องนี้ ให้ตรวจสอบพอร์ตที่เปิดใช้งาน (published ports) ก่อนที่จะถือว่างานเสร็จสิ้น Docker จะเขียนกฎของตนเองลงในตารางเดียวกันและ เปิดพอร์ต container ข้าม ufw ไปโดยตรง ดังนั้นนโยบาย deny ของ ufw จึงไม่ใช่ภาพรวมทั้งหมดของระบบความปลอดภัย

รีบูตก่อนที่จะเชื่อถือระบบ

systemctl is-enabled tor@default
sudo reboot

หากคำสั่งแรกไม่แสดงสถานะว่า service ถูกเปิดใช้งาน ให้รัน sudo systemctl enable tor@default ก่อนที่คุณจะรีบูต รอเป็นเวลา 2 นาที แล้วจึงรัน ssh myvps เนื่องจาก Tor ต้องทำการ bootstrap หลังจากบูตเครื่อง onion address จึงจะเริ่มตอบสนองหลังจากที่เครื่องทำงานไปแล้วระยะหนึ่ง

หากบริการไม่กลับมาทำงาน ให้เปิด console แล้วอ่าน sudo journalctl -u tor@default -b ข้อผิดพลาดทางไวยากรณ์ใน torrc หรือปัญหาเรื่องสิทธิ์ของไดเรกทอรีจะถูกแสดงไว้ที่นั่น คุณยังสามารถตรวจสอบการแก้ไขไฟล์ torrc ก่อนที่จะนำไปใช้งานจริงได้อีกด้วย

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

ต้นทุนที่ต้องแลกเมื่อเทียบกับ WireGuard tunnel

เมื่อเปรียบเทียบกับ การใช้ WireGuard VPN บน VPS ของคุณเอง บริการ onion service จะมีความเร็วต่ำกว่าและคาดการณ์ประสิทธิภาพได้ยากกว่า คุณควรพิจารณาข้อแลกเปลี่ยนเหล่านี้อย่างตรงไปตรงมาก่อนตัดสินใจเลือกใช้งาน

ความหน่วง (Latency): วงจรการเชื่อมต่อของไคลเอนต์ประกอบด้วย relay 3 ตัว และฝั่งบริการเพิ่มอีก 3 ตัว ดังนั้นการกดคีย์บอร์ดของคุณจะต้องผ่านเครื่องคอมพิวเตอร์ประมาณ 6 เครื่องที่ถูกสุ่มเลือกจากทั่วโลก การพิมพ์โต้ตอบจะมีอาการหน่วงให้เห็นชัดเจน และการคัดลอกไฟล์จะทำได้ช้า ในขณะที่ WireGuard เพิ่มเพียง hop เดียวเท่านั้น คุณควรวัดค่าด้วยตนเองโดยใช้ time ssh myvps 'echo ok' เนื่องจากตัวเลขจะขึ้นอยู่กับวงจรที่ tor สร้างขึ้นในขณะนั้นและจะเปลี่ยนไปเมื่อ tor สร้างวงจรใหม่

การทำงานของ daemon ในระดับ userspace บนเส้นทางวิกฤต: WireGuard ทำงานอยู่ใน kernel และพร้อมใช้งานทันทีที่เครือข่ายเริ่มทำงาน แต่ Tor เป็นกระบวนการ (process) ที่ต้องเริ่มทำงาน, ทำการ bootstrap และเชื่อมต่อกับ guard relay ให้สำเร็จก่อนจึงจะใช้งานได้ หากเกิดความล้มเหลว คุณจะต้องเข้าไปแก้ไขผ่านคอนโซลของผู้ให้บริการ

ความแม่นยำของเวลา: ตัวระบุ (descriptor) ของ onion service จะถูกเผยแพร่ตามช่วงเวลา ดังนั้นหากนาฬิกาของระบบไม่ตรงอย่างมาก จะทำให้การค้นหาที่อยู่ล้มเหลวโดยไม่มีข้อความแจ้งเตือนที่ชัดเจน timedatectl ควรรายงานค่าเป็น System clock synchronized: yes

สิ่งที่คุณได้รับเป็นการตอบแทนคือการเข้าถึงที่ไม่ขึ้นอยู่กับความถูกต้องของกฎ firewall อีกต่อไป ไม่มีการเปิดพอร์ตให้สแกนและไม่มี banner ให้ดึงข้อมูล ที่อยู่ของบริการคือ public key ในตัวมันเอง ดังนั้นจุดปลายทาง (endpoint) จะพิสูจน์ตัวตนได้ก่อนที่ SSH จะเริ่มทำงานเสียอีก

คำตอบในทางปฏิบัติมักจะเป็นการใช้ทั้งสองอย่างร่วมกัน โดยใช้ WireGuard เป็นเส้นทางหลักในการใช้งานประจำวัน และเก็บ onion service ไว้เป็นเส้นทางสำรองที่ยังคงใช้งานได้แม้การตั้งค่า WireGuard จะผิดพลาด วิธีนี้จะทำให้คุณเปิดเพียงพอร์ต UDP เดียว แทนที่จะเปิดพอร์ต SSH ต่อสาธารณะ อย่างไรก็ตาม วิธีการทั้งหมดนี้ไม่สามารถทดแทน การทำ hardening ให้กับ sshd ได้ การใช้การยืนยันตัวตนด้วย key เท่านั้นและการล็อกอินด้วยบัญชีที่ไม่ใช่ root ยังคงมีความสำคัญ เพราะ onion service ทำหน้าที่ปกป้องเพียงเส้นทางเครือข่ายเท่านั้น ไม่ได้ครอบคลุมถึงส่วนอื่นที่อยู่ถัดจากนั้น

รูปแบบความล้มเหลวและข้อผิดพลาดที่คุณจะพบ

Tor ไม่ผ่าน Bootstrapped 0% ทราฟฟิกขาออกถูกบล็อก หรือเวลาของระบบไม่ตรงอย่างมาก ให้ตรวจสอบนโยบายขาออกด้วย 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 ยังไม่ได้ถูกเผยแพร่ ซึ่งต้องใช้เวลาสักครู่หลังจากโหลดใหม่ หรือ tor บนเซิร์ฟเวอร์ไม่ได้ทำงานอยู่

F4, "Onion Service Missing Client Authorization" ไคลเอนต์ไม่มี .auth_private ที่ตรงกันซึ่ง tor สามารถใช้งานได้ ให้ตรวจสอบว่า ClientOnionAuthDir อยู่ใน torrc แล้ว, ไดเรกทอรีมีสิทธิ์เป็น 0700, ชื่อไฟล์ลงท้ายด้วย .auth_private และ debian-tor สามารถอ่านไฟล์ดังกล่าวได้

F5, "Onion Service Wrong Client Authorization" private key ไม่ตรงกับไฟล์ .auth บนเซิร์ฟเวอร์ การมี = ต่อท้ายหรือมีอักขระขึ้นบรรทัดใหม่ที่เกินมาภายในสตริง base32 จะทำให้เกิดข้อผิดพลาดนี้

nc: invalid option -- 'X' มีการติดตั้ง GNU netcat แทนที่จะเป็นเวอร์ชัน OpenBSD ให้รัน sudo apt install -y netcat-openbsd

Could not resolve hostname ssh พยายามใช้ DNS ปกติซึ่งไม่มีคำตอบสำหรับ .onion ทำให้ ProxyCommand ไม่เคยทำงาน รูปแบบ Host ใน ~/.ssh/config ไม่ตรงกับชื่อที่คุณพิมพ์

Permission denied (publickey) ทันเนลทำงานได้และ tor ทำงานเสร็จสิ้นแล้ว ให้จัดการปัญหานี้เสมือนเป็น ปัญหา permission denied publickey ทั่วไป โดยไม่ต้องนำ tor มาเกี่ยวข้อง

FAQ

การใช้ onion service หมายความว่า VPS จะไม่มีพอร์ตเปิดอยู่เลยใช่หรือไม่?

ใช่ เมื่อ sshd ถูกผูกไว้กับ 127.0.0.1 และ firewall ปฏิเสธการเชื่อมต่อขาเข้าทั้งหมด Tor จะสร้างการเชื่อมต่อ TCP ขาออกไปยัง relay และเซสชันของคุณจะเดินทางย้อนกลับผ่านเส้นทางนั้น ดังนั้นจึงไม่มีบริการใดบนเครื่องที่ยอมรับการเชื่อมต่อผ่าน public address คุณสามารถตรวจสอบได้ด้วย ss -tlnp บนเซิร์ฟเวอร์และทำการ port scan จากภายนอก อย่าลืมตรวจสอบ network firewall ของผู้ให้บริการใน control panel ซึ่งเป็นการควบคุมแยกต่างหากจาก ufw และต้องปิดการใช้งานด้วยเช่นกัน

.onion address เพียงพอต่อความปลอดภัยสำหรับ SSH แล้วหรือไม่?

ไม่เพียงพอ แม้ว่า address จะมีความยาว 56 ตัวอักษรและไม่สามารถเดาหรือไล่เรียงจาก directory system ได้ ทำให้มันทำหน้าที่เสมือนความลับ แต่ก็อาจรั่วไหลผ่าน shell history และไฟล์ config ได้ ควรเพิ่ม v3 client authorisation เข้าไปด้วย ซึ่งจะทำให้ service descriptor ถูกเข้ารหัสด้วย client key ของคุณ ดังนั้นผู้ที่มีเพียง address จะได้รับข้อผิดพลาด extended error F4 และไม่สามารถเข้าถึง sshd ได้เลย

จะเกิดอะไรขึ้นหาก tor ไม่เริ่มทำงานหลังการ reboot?

คุณจะสูญเสียการเข้าถึง SSH โดยสิ้นเชิง เนื่องจาก onion address เป็นช่องทางเดียวในการเข้าถึง นี่คือเหตุผลว่าทำไมจึงต้องทดสอบผ่าน console ของผู้ให้บริการก่อนที่จะปิดพอร์ต 22 นอกจากนี้ Tor ยังต้องใช้เวลาในการ bootstrap หลังจากบูตเครื่อง ดังนั้น address จะยังไม่ตอบสนองจนกว่าเครื่องจะพร้อมใช้งานหลังจาก ping ได้แล้ว หากยังไม่ตอบสนอง ให้ล็อกอินผ่าน console และอ่าน sudo journalctl -u tor@default -b ซึ่งจะแสดงข้อผิดพลาดทางไวยากรณ์ใน torrc หรือปัญหาด้านสิทธิ์บน /var/lib/tor/ssh

SSH ผ่าน Tor ช้ากว่า WireGuard หรือไม่?

ใช่ ช้ากว่ามาก การเชื่อมต่อกับ onion service จะผ่าน relay ประมาณหกจุดที่ถูกสุ่มเลือก ในขณะที่ WireGuard เป็นการกระโดดแบบเข้ารหัสเพียงจุดเดียวตรงไปยังเซิร์ฟเวอร์ของคุณ การพิมพ์จะรู้สึกหน่วงและรับส่งข้อมูลได้ช้า การตั้งค่าที่นิยมคือใช้ WireGuard สำหรับการทำงานทั่วไป และเก็บ onion service ไว้เป็นเส้นทางสำรองฉุกเฉินในกรณีที่การตั้งค่า VPN มีปัญหา