איך להקשיח SSH בשרת VPS: מדריך מעשי

מדוע SSH הוא הדבר הראשון שיש להקשיח

SSH הוא הדרך שבה אתם שולטים בשרת שלכם, מה שהופך אותו למנעול שכל תוקף מנסה לפרוץ ראשון. ברגע ששרת VPS עולה לאוויר, סורקים מתחילים לנחש שמות משתמש וסיסמאות בפורט 22. אתם יכולים לצפות בזה קורה בלוגים שלכם בתוך דקות. הקשחת SSH עוסקת בהסרת הדברים שהם יכולים לנחש: בטלו כניסה באמצעות סיסמה לחלוטין, בטלו כניסה של root, ואפשרו כניסה רק באמצעות מפתחות קריפטוגרפיים. ברגע שתעשו זאת, הניחושים הבלתי פוסקים פשוט לא יוכלו להצליח, כיוון שאין סיסמה שניתן למצוא.

הנחת היסוד היא ש־SSH כבר עובד אצלכם. אם אתם מצליחים להתחבר, אתם יכולים להקשיח אותו. בצעו את השלבים לפי הסדר והשאירו את הסשן הנוכחי שלכם פתוח עד שסשן חדש יעבוד, כדי שטעות לא תנעל אתכם מחוץ לשרת.

שלב 1: ודאו תחילה שאימות באמצעות מפתח עובד

אימות באמצעות מפתח מחליף את הסיסמה בזוג מפתחות: מפתח פרטי שנשאר במחשב שלכם ומפתח ציבורי שאתם מציבים בשרת. השרת מוודא שאתם מחזיקים במפתח הפרטי מבלי שהוא יעזוב את המחשב שלכם מעולם. לפני שתנטרלו סיסמאות, ודאו שמפתחות עובדים, אחרת תינעלו מחוץ לשרת.

במחשב האישי שלכם, צרו מפתח אם אין לכם אחד כזה:

ssh-keygen -t ed25519

העתיקו את החלק הציבורי לשרת:

ssh-copy-id user@your-server

לאחר מכן, פתחו session חדש של SSH. אם המערכת מאפשרת לכם להיכנס מבלי לבקש סיסמה, המפתח שלכם עובד ואתם יכולים בבטחה לבטל את השימוש בסיסמאות. אם המערכת חוסמת אתכם עם Permission denied (publickey), שגיאה זו מסתירה חמש תקלות שונות, והפלט של ssh -v יציין איזו מהן רלוונטית אליכם לפני שתשנו דבר מה נוסף. אם מפתחות הם נושא חדש עבורכם, או אם אתם משתמשים ביותר ממחשב אחד, יסודות ניהול מפתחות SSH מסביר את המודל המלא: מפתח אחד לכל התקן, ההרשאות ש-sshd דורש, וכיצד לבטל מפתח כאשר מחשב נייד הולך לאיבוד.

שלב 2: הקשחת sshd באמצעות קובץ drop-in

אל תערכו את /etc/ssh/sshd_config ישירות. גרסה Ubuntu 24.04 קוראת קובצי drop-in מתוך /etc/ssh/sshd_config.d/, וקובץ קטן שם הוא פתרון נקי יותר, ששורד שדרוגי חבילות וקל להסרה אם משהו משתבש. לשם הקובץ יש חשיבות: sshd שומר את הערך הראשון שהוא קורא עבור כל הגדרה, ותמונות הענן של Ubuntu כוללות את 50-cloud-init.conf עם PasswordAuthentication yes בתיקייה זו. תנו לקובץ שלכם את השם 00- כדי שימוין לפני הקובץ ההוא ויקבל עדיפות; קובץ בשם 99- יפסיד בשקט. צרו קובץ כזה:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

הכניסו לתוכו את התוכן הבא:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

כל שורה סוגרת דלת. PasswordAuthentication no היא החשובה ביותר: כאשר סיסמאות מבוטלות, למתקפת brute-force אין מה לתקוף. KbdInteractiveAuthentication no חוסמת נתיב נוסף המבוסס על סיסמאות. PermitRootLogin no מחייבת תוקף לדעת את שם המשתמש שלכם ולהחזיק במפתח שלכם, במקום פשוט לנסות לפרוץ לחשבון ה-root שקיים בכל שרת.

שלב 3: בדיקת התצורה וטעינה מחדש

בדקו את התצורה לאיתור שגיאות לפני החלתה, כדי ששגיאת הקלדה לא תשבית את השירות:

sudo sshd -t

אם הפקודה אינה מציגה פלט, התצורה תקינה. טענו מחדש את SSH:

sudo systemctl reload ssh

לאחר מכן, בדקו את ההגדרות ש-sshd משתמש בהן בפועל, כדי לוודא שקובץ drop-in לא נדרס על ידי קובץ אחר:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

שני הערכים צריכים להציג no. כעת, מבלי לסגור את הסשן הנוכחי, פתחו סשן חדש לגמרי מטרמינל אחר. אם הצלחתם להתחבר באמצעות המפתח, סיימתם. אם משהו אינו תקין, הסשן הראשון שלכם עדיין פתוח כדי לאפשר תיקון. חפיפה זו היא רשת הביטחון שלכם, לכן לעולם אל תדלגו עליה.

שלב 4: שימוש בפורט לא סטנדרטי (אופציונלי)

העברת SSH מפורט 22 לפורט אחר, כמו 2222, אינה משפרת את האבטחה באופן ממשי, כיוון שתוקף נחוש יסרוק את כל הפורטים. פעולה זו מפחיתה את רעשי הלוגים, שכן רוב הסורקים האוטומטיים מנסים להתחבר רק לפורט 22. אם ברצונכם לבצע זאת, הוסיפו את Port 2222 לקובץ ה-drop-in שלכם, אפשרו תחילה את הפורט החדש ב-firewall, ולאחר מכן הריצו את sudo systemctl daemon-reload && sudo systemctl restart ssh.socket והתחברו באמצעות ssh -p 2222. ב-Ubuntu 24.04, ה-ssh.socket הוא שאחראי על הפורט המאזין, לכן הרצה רגילה של reload ssh תשאיר את sshd על פורט 22; הפעלה מחדש של ה-socket היא הפעולה שמעדכנת את הפורט החדש. התייחסו לכך כאל סדר וארגון, לא כאל אמצעי הגנה.

שלב 5: הוספת שכבות הגנה נוספות

מפתחות SSH מוקשחים הם הבסיס, ועליהם מתווספות שתי שכבות הגנה נוספות.

Fail2ban מנטר את הלוגים שלכם וחוסם כתובות שממשיכות להיכשל בניסיונות התחברות; פעולה זו מצמצמת את רעשי הסורקים ומסלקת אותם בשלב מוקדם. הוא משתלב היטב עם אימות מבוסס מפתחות בלבד: ראו Fail2ban ב-Ubuntu לעצירת התקפות SSH.

אפשרות חזקה עוד יותר היא הרחקת SSH מהאינטרנט הציבורי לחלוטין. אם תציבו את SSH מאחורי WireGuard VPN ותחסמו את פורט 22 ב-firewall לטובת ה-tunnel, אף גורם מחוץ ל-VPN לא יוכל להגיע אליו, וניסיונות brute-force יהפכו לבלתי אפשריים במקום להיות רק קשים לביצוע. כל זה מניח קיומו של firewall עם מדיניות default-deny ברקע, כפי שמוגדר ב-הגדרת UFW ב-VPS.

SSH הוא רק שורה אחת ברשימת תיוג רחבה יותר: עשר הדקות הראשונות ב-VPS חדש מסדרות את השלבים לפי סדר חשיבות, ו-עדכוני אבטחה אוטומטיים ב-Ubuntu שומרים על השרת מעודכן לאחר מכן. נעילת הדלת אינה מועילה לשירותים שנמצאים מאחוריה; לכן, אם אותו VPS מריץ כספת סיסמאות, סבב הקשחה ל-Vaultwarden מכסה את שני הדברים שאימות מפתחות אינו נוגע בהם: ה-admin token וקובץ הגיבוי.

FAQ

כיצד אוכל להשבית התחברות באמצעות סיסמה עבור SSH ב-Ubuntu 24.04?

צרו קובץ drop-in בנתיב /etc/ssh/sshd_config.d/00-hardening.conf (התחילית 00 מבטיחה שהוא ימוין לפני 50-cloud-init.conf, שהערך PasswordAuthentication yes שבו היה גובר אחרת, כיוון ש-sshd שומר את הערך הראשון שהוא קורא) המכיל את PasswordAuthentication no ואת KbdInteractiveAuthentication no. הריצו את sudo sshd -t כדי לבדוק את התקינות, ולאחר מכן את sudo systemctl reload ssh. ודאו שהתחברות באמצעות מפתח עובדת בסשן חדש לפני שתסתמכו עליה. עריכת קובץ drop-in במקום עריכת sshd_config שורדת שדרוגי חבילות וקלה לביטול.

האם עליי להשבית התחברות כ-root דרך SSH?

כן. הגדירו PermitRootLogin no כדי שאף אחד לא יוכל להתחבר ישירות כ-root. התחברו כמשתמש רגיל והשתמשו ב-sudo עבור משימות ניהול. משתמש root קיים בכל מערכת Linux, לכן השארתו נגישה מעניקה לתוקף שם משתמש ידוע למתקפה. השבתת גישה זו מחייבת את התוקף לדעת את שם המשתמש שלכם ולהחזיק במפתח שלכם.

האם שינוי פורט ה-SSH הופך את השרת שלי למאובטח יותר?

לא באופן משמעותי. מעבר מפורט 22 מסתיר אתכם מסורקים עצלנים שבודקים רק את פורט 22, מה שמפחית את הרעש בלוגים, אך תוקף אמיתי יסרוק את כל הפורטים וימצא אותו בכל מקרה. אימות מבוסס מפתחות בלבד הוא מה שבאמת עוצר פריצות. אם אתם משנים את הפורט, פתחו תחילה את הפורט החדש ב-firewall, ולאחר מכן הריצו את sudo systemctl daemon-reload && sudo systemctl restart ssh.socket; ב-Ubuntu 24.04 ה-socket הוא שמחזיק ב-listener, וביצוע reload רגיל ישאיר את sshd על פורט 22.

האם אני זקוק ל-Fail2ban אם אני משתמש במפתחות SSH?

זה אופציונלי אך עדיין שימושי. עם אימות מבוסס מפתחות בלבד, ניחוש סיסמאות אינו יכול להצליח, לכן Fail2ban אינו הגורם שמונע חדירת תוקפים. הוא מגביל קצב של ניסיונות כושלים חוזרים מכתובת אחת, מה שמפחית רעש של סורקים מהלוגים שלכם ומסלק מוקדם תוקפים סדרתיים; מתקפה איטית ומבוזרת תישאר ממילא מתחת לסף החסימה שלו. הריצו אותו בנוסף לאימות מפתחות, ובאופן אידיאלי שמרו את SSH מאחורי VPN.

כיצד אוכל לשחזר גישה אם ננעלתי מחוץ ל-SSH?

השתמשו ב-web console של ספק השרת שלכם, שמגיע לשרת דרך חיבור serial או VNC שאינו עובר דרך SSH. משם תוכלו להתחבר, לתקן את קובץ ה-drop-in ב-sshd ולבצע reload לשירות. זו בדיוק הסיבה לכך שבודקים תצורת SSH חדשה בטרמינל שני לפני שסוגרים את הסשן הראשון, וזו הסיבה לכך שאימות מפתחות צריך לעבוד כבר לפני שאתם מכבים את השימוש בסיסמאות.