חיבור SSH דרך Tor Onion ללא פתיחת פורטים בשרת

מה משתנה בשימוש ב-SSH מעל שירות Onion של Tor

שימוש ב-SSH מעל שירות Onion של Tor מאפשר לנהל שרת VPS שאינו מקבל חיבורים נכנסים באף פורט. השרת יוצר קשר יוצא לרשת Tor ומחזיק את החיבור פתוח. סשן ה-SSH שלכם מגיע דרך חיבור זה, כך שאין צורך להאזין לפורטים בכתובת ה-IP הציבורית.

ההשפעה על הלוגים מיידית. שרת עם פורט SSH ציבורי פתוח אוסף אלפי ניסיונות התחברות כושלים ביום מצד סורקים. העבירו את sshd אל מאחורי שירות Onion וחסמו תעבורה נכנסת ב-firewall, ו-/var/log/auth.log יתעד מעתה רק את הסשנים שאתם יזמתם.

המחיר הוא ש-tor נמצא בנתיב של כל סשן ניהול. זהו daemon הפועל במרחב המשתמש (userspace) שחייב לעלות ולהשלים את תהליך ה-bootstrap לאחר כל אתחול לפני שתוכלו להתחבר. תכננו זאת לפני סגירת הפורט, שכן במקרה של כשל, אתם עלולים לאבד גישה למכונה שאין לכם אליה גישה פיזית.

הבטחת דרך גישה חלופית לפני ביצוע שינויים

אל תתחיל בתהליך לפני שיש בידך נתיב שחזור שאינו מסתמך על SSH.

פתח כעת את הקונסולה של ספק השרתים שלך, ה־VNC או ה־serial console בלוח הבקרה, והתחבר דרכה. אם סיסמת ה-root אינה ידועה, אפס את סיסמת ה-root מלוח הבקרה תחילה וודא שהיא עובדת. קונסולה שמעולם לא בדקת אינה נחשבת לנתיב שחזור.

לסדר הפעולות להלן יש חשיבות. כל שלב מאומת לפני ביצוע השלב הבא, ופורט 22 נשאר פתוח עד שהחיבור דרך ה-onion פועל.

1. התקן את tor וודא שהוא מבצע bootstrap בהצלחה.
2. הגדר את ה-onion service וקרא את הכתובת שנוצרה.
3. התחבר דרך ה-onion בזמן שפורט 22 עדיין פתוח.
4. הוסף הרשאת לקוח (client authorisation), ולאחר מכן התחבר שוב.
5. קשור את sshd ל-loopback וסגור את פורט 22.
6. בצע reboot, ולאחר מכן התחבר שוב דרך ה-onion.

השאר את סשן ה-SSH הנוכחי שלך פתוח לאורך כל התהליך. סשן פעיל שורד שינוי ב-firewall שחוסם חיבורים חדשים, ולכן הוא קו ההגנה הראשון שלך למקרה של תקלה.

התקנת tor על השרת

הפצת Ubuntu כוללת את tor במאגרים שלה, אך גרסה זו לרוב אינה מעודכנת. המאגר של The Tor Project מכיל את הגרסה המתוארת בתיעוד שלהם. הוסיפו אותו באמצעות הפקודות המופיעות ב-מדריך מאגרי ה-apt שלהם.

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 משתמשת בשם הקוד של ההפצה שלכם, אותו 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

הלוג אמור להסתיים ב-Bootstrapped 100% (done). אם התהליך נתקע מתחת לשורה זו, סימן ש-tor אינו מצליח להגיע לרשת; לרוב מדובר בחוק firewall יוצא או בשעון מערכת שאינו מכוון.

שם ה-unit הוא מלכודת. הפקודה systemctl status tor מדווחת על Active: active (exited) גם כשהכול תקין, כיוון ש-Debian ו-Ubuntu אורזות את tor כיחידת master מרובת-מופעים, שתפקידה היחיד הוא להפעיל את המופע האמיתי. ה-daemon עצמו רץ כ-tor@default.service. השתמשו בשם זה עבור status ועבור journalctl. פקודות start, stop ו-reload עבור tor אכן מגיעות למופע, לכן sudo systemctl reload tor עובד כצפוי.

הגדרת שירות onion עבור פורט 22

הוסיפו שתי שורות לקובץ /etc/tor/torrc.

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

השורה השנייה מורה ל-tor לקבל תעבורה בפורט וירטואלי 22 בכתובת ה-onion ולהתחבר ל-127.0.0.1:22 בשרת. Tor מגיע אל sshd דרך ה-loopback, וזו בדיוק הסיבה ש-sshd יכול להפסיק להאזין בכתובת הציבורית בהמשך.

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

פקודה זו מדפיסה 56 תווים בבסיס 32 ואחריהם .onion. תווים אלו הם המפתח הציבורי של השירות בצורה מקודדת. אין כאן רשות אישורים (CA) ואין רישום שמות בשום מקום.

תנו ל-tor ליצור את /var/lib/tor/ssh/ בעצמו. אם תיצרו אותו ידנית עם בעלים שגוי או הרשאות רופפות מ-0700, tor יסרב להשתמש בו, וה-journal ידווח שהספרייה פתוחה מדי להרשאות. הקבצים שבפנים הם זהות השירות: hs_ed25519_secret_key הוא הכתובת. בצעו גיבוי לספרייה זו עם הרשאות 600 ושמרו את העותק מחוץ לשרת, כיוון שאובדן הקבצים משמעו כתובת חדשה וצורך בעדכון הגדרות בכל לקוח.

התחברות מתחנת העבודה שלכם

תחנת העבודה שלכם זקוקה ללקוח Tor, שאינו דורש כל הגדרה. ב-Debian או ב-Ubuntu, החבילה היא sudo apt install -y tor netcat-openbsd. לאחר מכן, Tor מאזין ב-127.0.0.1:9050 כ-SOCKS5 proxy. הפרוטוקול SOCKS הוא פרוטוקול proxy גנרי, וגרסה 5 מסוגלת להעביר שם מארח (hostname) במקום כתובת IP, וזהו החלק החשוב כאן.

ל-OpenSSH אין לקוח SOCKS מובנה, לכן תוכנית עזר מבצעת את החיבור. הוסיפו את התוכן הבא ל-~/.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 פותר אותו בתוך הרשת. עליכם להשתמש ב-netcat של OpenBSD. ל-netcat של GNU אין את האפשרות -X והוא יפסיק את פעולתו עם השגיאה nc: invalid option -- 'X'.

ssh myvps

החיבור הראשון איטי, מכיוון ש-Tor בונה מעגל (circuit) לפני שמתרחש דבר מה אחר. אשרו את ה-fingerprint של מפתח המארח כפי שהייתם עושים בכל מקרה אחר. מכאן ואילך, טיפול רגיל במפתחות SSH תקף ללא שינוי. התעבורה עברה מסלול, אך תהליך האימות נותר ללא שינוי.

עבור חיבור חד-פעמי, ניתן לדלג על הגדרת הקובץ: הפקודה torsocks ssh admin@xxxxx.onion מבצעת את אותה הפעולה.

הוספת אימות לקוח v3

במצבו הנוכחי, כל מי שלומד את הכתובת יכול להגיע ל-banner של ה-SSH שלכם ולהתחיל בניסיונות ניחוש. לא ניתן לבצע enumeration לכתובות Onion מתוך מערכת ה-directory, לכן הכתובת מתפקדת כסוד, אך היא דולפת בדרכים רגילות: היסטוריית shell, וקבצי תצורה שבוצעו להם commit למאגר git. אימות לקוח סוגר את הפרצה הזו. השירות מפרסם את ה-descriptor שלו כשהוא מוצפן עבור מפתח לקוח, כך שמי שמחזיק בכתובת אך אין לו מפתח, אינו יכול אפילו לאתר את השירות.

צרו זוג מפתחות x25519 בלקוח. זהו ה-pipeline מתוך מדריך אימות הלקוח של פרויקט Tor, עם שינוי אחד.

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, לכן השתמשו בו במקום.

בשרת, התקינו את המפתח הציבורי.

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 יתעלם מהקובץ ללא הדפסת שגיאה, והשירות יישאר פתוח בשקט לכל מי שמחזיק בכתובת.

בלקוח, התקינו את המפתח הפרטי. ב-Ubuntu, ה-daemon של tor רץ כמשתמש 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 של הלקוח וטענו מחדש את 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 בכתובת הציבורית. ב-Ubuntu 24.04, השירות ssh מופעל דרך יחידת socket, לכן 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= מנקה את הערך שעבר בירושה מהיחידה המותקנת. השמטת שורה זו תוסיף מאזין שני תוך שמירה על המאזין הציבורי; זו הדרך הנפוצה ביותר שבה שלב זה נכשל מבלי להציג שגיאה מפורשת.

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

השאירו תעבורה יוצאת מותרת. Tor מתחבר החוצה ל-relays בפורטים כמו 443 ו-9001, לכן מדיניות של default-deny לתעבורה יוצאת תעצור את תהליך ה-bootstrapping של Tor ותחסום בו-זמנית את הדרך היחידה שנותרה לכם להיכנס פנימה. רוב ספקי השרתים מפעילים firewall רשתי נפרד בלוח הבקרה. סגרו את פורט 22 גם שם, אחרת הפורט יישאר נגיש ללא קשר למה ש-ufw מדווח.

אם Docker רץ על השרת, בדקו את הפורטים המפורסמים שלו לפני שתכריזו על סיום המשימה. Docker כותב חוקים משלו לאותן טבלאות ו-מפרסם פורטים של מכולות ישירות מעבר ל-ufw, כך שמדיניות deny ב-ufw אינה משקפת את התמונה המלאה.

בצעו אתחול לפני שתסמכו על השירות

systemctl is-enabled tor@default
sudo reboot

אם הפקודה הראשונה לא מדווחת שהשירות מופעל (enabled), הריצו את sudo systemctl enable tor@default לפני שתבצעו אתחול. המתינו שתי דקות, ולאחר מכן הריצו את ssh myvps. השירות Tor נדרש לבצע תהליך bootstrap לאחר העלייה, לכן כתובת ה-onion תתחיל להגיב זמן מה לאחר שהמכונה עצמה כבר פעילה.

אם השירות לא חוזר לפעילות, פתחו את ה-console וקראו את sudo journalctl -u tor@default -b. שגיאת syntax בקובץ torrc או בעיית הרשאות בתיקייה יודפסו שם. ניתן גם לבדוק את התקינות של עריכה בקובץ torrc לפני החלתה.

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

מה העלות של זה בהשוואה למנהרת WireGuard

בהשוואה ל-VPN מבוסס WireGuard על שרת VPS פרטי, שירות onion הוא איטי ופחות צפוי. היו כנים עם עצמכם לגבי הפשרה הזו לפני שתתחייבו אליה.

שיהוי (Latency). מעגל לקוח מורכב משלושה ממסרים (relays) וצד השירות מוסיף שלושה נוספים, כך שהקשות המקלדת שלכם עוברות דרך כשישה מחשבים שנבחרו באקראי ברחבי העולם. הקלדה אינטראקטיבית סובלת מעיכוב מורגש, והעתקת קבצים היא איטית. WireGuard מוסיף דילוג (hop) אחד בלבד. מדדו את המקרה שלכם בעזרת time ssh myvps 'echo ok', כיוון שהנתון תלוי במעגל ש-tor בנה באותו רגע והוא משתנה כאשר tor בונה מעגל חדש.

תהליך ברמת המשתמש (userspace daemon) בנתיב הקריטי. WireGuard פועל ברמת ה-kernel ועולה יחד עם הרשת. Tor הוא תהליך שחייב לעלות, לבצע bootstrap ולהגיע ל-guard relay לפני שכל דבר אחר יעבוד. כאשר הוא נכשל, תצטרכו להשתמש ב-console של ספק השרת.

דיוק שעון. מתארי שירותי onion מתפרסמים לפי טווחי זמן, לכן שעון שאינו מכוון היטב ישבש את איתור הכתובת ללא הודעת שגיאה ברורה. timedatectl אמור לדווח על System clock synchronized: yes.

מה שאתם מקבלים בתמורה הוא חשיפה שאינה תלויה עוד בתקינות חוקי ה-firewall. אין פורט לסריקה ואין banner לשליפה, והכתובת עצמה היא מפתח ציבורי, כך שנקודת הקצה מוכיחה את זהותה עוד לפני ש-SSH מתחיל לפעול.

התשובה הפרקטית היא בדרך כלל שילוב של שניהם. הריצו WireGuard כנתיב היומיומי, ושמרו את שירות ה-onion כנתיב שעדיין עובד כאשר הגדרות ה-WireGuard שגויות. כך נשאר פורט UDP אחד פתוח במקום פורט SSH ציבורי. שום דבר מזה לא מחליף את הקשחת sshd עצמו: אימות מבוסס מפתחות בלבד וכניסה למשתמש שאינו root עדיין חשובים, כיוון ששירות onion מגן על נתיב הרשת ולא על שום דבר מעבר לו.

מצבי כשל ושגיאות נפוצות

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". ייתכן שהמתאר טרם פורסם (תהליך שלוקח זמן קצר לאחר טעינה מחדש), או ש-tor בשרת אינו פעיל.

F4, "Onion Service Missing Client Authorization". ללקוח אין .auth_private תואם ש-tor יכול להשתמש בו. ודאו ש-ClientOnionAuthDir מוגדר ב-torrc, שהרשאות התיקייה הן 0700, ששם הקובץ מסתיים ב-.auth_private, ושהמשתמש debian-tor מורשה לקרוא אותו.

F5, "Onion Service Wrong Client Authorization". המפתח הפרטי אינו תואם לקובץ .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 סיים את תפקידו. התייחסו לכך כאל בעיית הרשאות רגילה של publickey והתעלמו מ-Tor בהקשר זה.

FAQ

האם שירות onion באמת אומר שאין פורטים פתוחים ב-VPS שלי?

כן, ברגע ש-sshd מאוגד ל-127.0.0.1 וה-firewall חוסם תעבורה נכנסת. Tor יוצר חיבור TCP יוצא ל-relay והסשן שלך עובר דרכו, כך ששום דבר בשרת לא מקבל חיבור בכתובת הציבורית. ניתן לוודא זאת באמצעות ss -tlnp בשרת וסריקת פורטים ממקור חיצוני. אל תשכח את ה-firewall של ספקית השרת בלוח הבקרה; זהו מנגנון נפרד מ-ufw שיש לסגור גם כן.

האם כתובת .onion מספקת אבטחה מספקת כשלעצמה עבור SSH?

לא. הכתובת באורך 56 תווים ולא ניתן לנחש או למנות אותה ממערכת ה-directory, לכן היא מתנהגת כסוד, אך היא עלולה לדלוף דרך היסטוריית ה-shell וקבצי תצורה. הוסף אימות לקוח v3. באמצעותו, ה-descriptor של השירות מוצפן עבור מפתח הלקוח שלך, כך שמי שמחזיק רק בכתובת יקבל שגיאה מורחבת F4 ולעולם לא יגיע ל-sshd.

מה קורה אם Tor לא עולה לאחר אתחול?

אתה מאבד גישה ל-SSH לחלוטין, כיוון שכתובת ה-onion היא הדרך היחידה פנימה. זו הסיבה שיש לבדוק את מסוף הספק לפני סגירת פורט 22. Tor זקוק גם לזמן כדי לבצע bootstrap לאחר עליית המערכת, לכן הכתובת תגיב מאוחר יותר מאשר המכונה תגיב ל-ping. אם היא לא מגיבה כלל, התחבר דרך המסוף וקרא את sudo journalctl -u tor@default -b, שם תופיע שגיאת תחביר ב-torrc או בעיית הרשאות ב-/var/lib/tor/ssh.

האם SSH מעל Tor איטי יותר מ-WireGuard?

כן, בפער ניכר. חיבור לשירות onion עובר דרך כשישה relays שנבחרים באקראי, בעוד ש-WireGuard הוא דילוג מוצפן אחד ישירות לשרת שלך. ההקלדה מרגישה איטית והעברות נתונים איטיות. תצורה נפוצה היא שימוש ב-WireGuard לעבודה יומיומית, כאשר שירות ה-onion נשמר כנתיב חירום ששורד תצורת VPN תקולה.