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

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

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

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

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

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

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

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

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

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

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

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

Ubuntu มี tor มาให้ใน repository ของตนเอง แต่เวอร์ชันดังกล่าวมักจะล้าหลังกว่าเวอร์ชันปัจจุบัน 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 ของ release ที่คุณใช้งาน ซึ่ง lsb_release -cs จะแสดงผลออกมา (ได้แก่ noble บน 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

log ควรจะสิ้นสุดด้วย Bootstrapped 100% (done) หากค้างอยู่ต่ำกว่าบรรทัดนั้น แสดงว่า tor ไม่สามารถเชื่อมต่อเครือข่ายได้ ซึ่งมักเกิดจากกฎของ firewall ขาออกหรือการตั้งค่าเวลาที่ไม่ถูกต้อง

ชื่อ unit เป็นสิ่งที่ควรระวัง systemctl status tor จะรายงาน Active: active (exited) แม้ว่าทุกอย่างจะทำงานปกติ เนื่องจาก Debian และ Ubuntu จัดแพ็กเกจ tor เป็น master unit แบบหลาย instance ซึ่งมีหน้าที่เพียงแค่เรียก 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 ในภายหลังได้

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 และเก็บสำเนาไว้นอกเครื่อง เพราะหากทำข้อมูลนี้หาย คุณจะต้องเปลี่ยนที่อยู่ใหม่และแก้ไขไฟล์ config บนไคลเอนต์ทุกเครื่อง

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

เวิร์กสเตชันของคุณจำเป็นต้องมี 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 ตามปกติ จะมีผลบังคับใช้โดยไม่มีการเปลี่ยนแปลง เนื่องจากมีการย้ายช่องทางการขนส่งข้อมูล (transport) เท่านั้น แต่ไม่ได้เปลี่ยนวิธีการยืนยันตัวตน

สำหรับการใช้งานเพียงครั้งเดียว คุณสามารถข้ามการตั้งค่าในไฟล์ 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 ซึ่งไม่สามารถอ่านไฟล์ในโฮมไดเรกทอรีของคุณได้ ดังนั้นควรเก็บไดเรกทอรีไว้ในตำแหน่งที่ผู้ใช้ดังกล่าวสามารถเข้าถึงได้

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 ของไคลเอนต์แล้ว reload 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 แยกต่างหากในแผงควบคุม ให้ปิดพอร์ต 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 เพิ่มเพียงแค่ 1 hop เท่านั้น ให้วัดค่าด้วยตัวคุณเองโดยใช้ time ssh myvps 'echo ok' เนื่องจากตัวเลขจะขึ้นอยู่กับวงจรที่ tor สร้างขึ้นและจะเปลี่ยนไปเมื่อ tor สร้างวงจรใหม่

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

ความแม่นยำของเวลา: Onion service descriptor จะถูกเผยแพร่ตามช่วงเวลา ดังนั้นหากนาฬิกาของระบบไม่ตรงอย่างมาก จะทำให้การค้นหาที่อยู่ล้มเหลวโดยไม่มีข้อความแจ้งเตือนที่ชัดเจน 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 แบบขยายรหัส F0 คือ "Onion Service Descriptor Can Not be Found" ซึ่งอาจเกิดจาก descriptor ยังไม่ได้ถูกเผยแพร่ (ต้องใช้เวลาสักครู่หลังจาก reload) หรือ 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 ของผู้ให้บริการในแผงควบคุมด้วย ซึ่งเป็นระบบที่แยกจาก ufw และต้องปิดการเชื่อมต่อขาเข้าในส่วนนั้นด้วยเช่นกัน

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

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

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

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

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

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