איך לאבטח SSH בשרת VPS

Why SSH is the first thing to harden

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

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

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

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

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

ssh-keygen -t ed25519

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

ssh-copy-id user@your-server

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

Step 2: Harden sshd with a drop-in file

אל תערוך את /etc/ssh/sshd_config ישירות. Ubuntu 24.04 קוראת drop-in files מתוך /etc/ssh/sshd_config.d/. קובץ קטן בתוך התיקייה הזו הוא פתרון נקי יותר, נשמר במהלך שדרוגי חבילות, וקל להסרה אם משהו משתבש. לשם הקובץ יש חשיבות: sshd שומר את הערך הראשון שהוא קורא עבור כל הגדרה, ו-Ubuntu cloud images כוללות את 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 הקיים בכל מכונה.

Step 3: Test the config, then reload

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

sudo sshd -t

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

sudo systemctl reload ssh

לאחר מכן בדקו את ההגדרות ש-sshd משתמש בהן בפועל. כך תוכלו לזהות הגדרה שהוחלפה על ידי קובץ אחר:

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

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

Step 4: פורט לא סטנדרטי (אופציונלי)

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

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

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

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

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

SSH הוא רק חלק מרשימת בדיקה רחבה יותר: the first 10 minutes on a new VPS מסודרת לפי סדר פעולות, ו-automatic security updates on Ubuntu מבטיח שהשרת יישאר מעודכן בתיקוני אבטחה.

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, מה שמפחית רעש ביומני הרישום (logs), אך תוקף אמיתי יסרוק כל פורט וימצא אותו בכל מקרה. אימות באמצעות מפתח בלבד הוא מה שבאמת מונע פריצות. אם אתם משנים את הפורט, פתחו תחילה את הפורט החדש בחומת האש, ולאחר מכן הריצו את sudo systemctl daemon-reload && sudo systemctl restart ssh.socket; ב-Ubuntu 24.04 ה-socket הוא הבעלים של ה-listener, וביצוע reload פשוט ישאיר את sshd בפורט 22.

האם אני צריך Fail2ban אם אני משתמש במפתחות SSH?

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

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

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