מה זה SSH ואיך הוא עובד? מדריך למשתמש

מהו SSH?

SSH (Secure Shell) הוא פרוטוקול להתחברות למחשב מרוחק והרצת פקודות עליו באמצעות חיבור מוצפן. כל מה שאתם מקלידים נשלח למכונה המרוחקת, הפלט שלה חוזר אליכם, ואף גורם המנטר את הרשת בתווך אינו יכול לקרוא את התעבורה. לשרת Linux מושכר אין מסך או מקלדת מחוברים, ולכן SSH הוא האמצעי שבאמצעותו נעשה שימוש במכונה.

השם מתייחס לשני דברים. SSH הוא הפרוטוקול, המתואר ב-RFC 4251 עד RFC 4254. OpenSSH היא התוכנה המממשת אותו, והיא התוכנה שרצה כמעט בכל שרת Linux ובכמעט כל מחשב נייד. כאשר מישהו אומר "SSH into the server", הוא מתכוון לתוכנת הלקוח ssh במחשב שלו המתקשרת עם תוכנת השרת sshd בצד השני.

הבעיה ש־SSH נועד להחליף

התחברות מרחוק קיימת זמן רב לפני SSH. פרוטוקול Telnet פתח חיבור TCP גלוי בפורט 23 ושלח כל בייט בדיוק כפי שהוקלד. שום דבר לא הוצפן, וזה כלל את הסיסמה שלכם. כל מי שיכול היה לראות את התעבורה היה מסוגל לקרוא אותה: אדם באותה רשת משרדית, או מפעיל של כל נתב לאורך הנתיב. משפחת הפקודות rlogin סבלה מאותה חולשה, והיא נתנה אמון במכונת הלקוח לפי שמה, מה שאומר מתן אמון בכל מה שהרשת טענה שהוא השם הזה.

Tatu Ylönen כתב את ה־SSH הראשון בשנת 1995 באוניברסיטת הלסינקי לטכנולוגיה, לאחר מתקפת "ציתות לסיסמאות" (password sniffing) ברשת האוניברסיטה. התכנון שומר על החלק השימושי של Telnet, כלומר זרם בייטים בין הטרמינל שלכם לבין מעטפת (shell) מרוחקת, ומוסיף את שני הדברים שאין ל־Telnet מענה עבורם: הצפנה של הזרם, והוכחה שהשרת בקצה השני הוא אכן השרת שאליו התכוונתם להגיע.

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

כיצד פועל מודל הלקוח-שרת

קיימות שתי תוכנות נפרדות. בשרת, sshd פועל באופן רציף וממתין לחיבורים. במחשב שלך, ssh יוצר אותם. אלו תוכנות נפרדות עם קובצי תצורה נפרדים, ובלבול ביניהן הוא הסיבה הנפוצה ביותר לכך ששינוי בהגדרות אינו משפיע.

• השרת קורא את /etc/ssh/sshd_config. זהו המקום שבו מושבתת ההתחברות באמצעות סיסמה ושבו מוגדר הפורט להאזנה.
• הלקוח קורא את /etc/ssh/ssh_config עבור הגדרות ברירת המחדל של המערכת, ולאחר מכן את ~/.ssh/config עבור הגדרות אישיות לכל מארח.

ב-Debian וב-Ubuntu יחידת השירות נקראת ssh. ב-RHEL, ב-Rocky וב-Fedora היא נקראת sshd. גרסאות Ubuntu עדכניות מתקינות אותו בתצורת socket activated, לכן systemctl status ssh עשוי לדווח על inactive (dead) בעוד המכונה נגישה לחלוטין, כיוון ש-ssh.socket היא היחידה שמבצעת את ההאזנה ומפעילה את השירות לפי דרישה.

הלקוח אינו חייב להיות OpenSSH. התוכנה PuTTY ב-Windows, האפליקציה Termius בטלפון, וכלי התמיכה המרוחק המובנים בעורכי טקסט, כולם משתמשים באותו פרוטוקול מול אותו sshd. מערכות Windows 10 ו-11 כוללות גם הן את הלקוח של OpenSSH, כך ש-ssh you@server עובד ב-PowerShell ללא צורך בהתקנה נוספת.

מדוע SSH משתמש בפורט 22?

פורט הוא מספר המורה ל-kernel לאיזו תוכנית מאזינה שייך חיבור נכנס, ו-פורטים ב-Linux פועלים באותה צורה עבור כל שירות. SSH משתמש ב-22 מכיוון ש-IANA הקצתה לו מספר זה בשנת 1995. Ylönen ביקש מספר פנוי שנמצא בסמוך לפרוטוקולים ש-SSH נועד להחליף: 21 היה FTP, 23 היה telnet, ו-22 היה פנוי.

מכיוון ש-22 הוא ברירת המחדל, הכל מניח שזהו הפורט בשימוש. ה-Git remote שלכם, סקריפט הגיבוי שלכם ולוח הבקרה של ספק השרתים שלכם – כולם מנסים קודם כל את 22. כך עושה גם כל סורק אוטומטי באינטרנט. שרת חדש עם כניסה מבוססת סיסמה מתחיל לצבור שורות כאלה ב-/var/log/auth.log תוך דקות מרגע העלייה:

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

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

ניתן לצפות בשרת משיב לפני שמתחברים כלל:

nc 203.0.113.10 22

ב-Ubuntu 24.04 הפקודה מדפיסה משהו קרוב ל-SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13. ה-banner נשלח בטקסט גלוי, לפני שקיימת הצפנה כלשהי, מכיוון ששני הצדדים זקוקים לו כדי להסכים על גרסת הפרוטוקול. הקישו Ctrl+C כדי לסגור את החיבור.

מה קורה על גבי הרשת בעת התחברות

הרצף הבא מתאר את הפעולות שמבצע ssh you@server לפני שמופיעה שורת הפקודה.

1. הלקוח מתרגם את שם המארח לכתובת IP, ולאחר מכן פותח חיבור TCP לפורט 22.
2. שני הצדדים שולחים את ה־banner של הגרסה שלהם בטקסט גלוי.
3. שני הצדדים שולחים את רשימות האלגוריתמים הנתמכים על ידם: החלפת מפתחות, צופן, אימות הודעות ודחיסה. שלב זה עדיין מתבצע בטקסט גלוי. האפשרות החזקה ביותר ששני הצדדים מכירים היא זו שנבחרת.
4. מתבצעת החלפת מפתחות. גרסאות OpenSSH עדכניות מעדיפות את curve25519-sha256. שני הצדדים מגיעים למצב שבו הם מחזיקים באותו סוד משותף, מבלי שהסוד הזה עבר אי פעם ברשת. לכן, מי שהקליט את כל השיחה לא יוכל לפענח אותה בדיעבד.
5. השרת חותם על תוצאת ההחלפה באמצעות המפתח הפרטי של המארח. הלקוח שלך בודק את החתימה מול המפתח הציבורי של המארח השמור אצלו. זהו השלב שמונע ממכונה בתווך להתחזות לשרת שלך.
6. ההצפנה מתחילה. chacha20-poly1305@openssh.com הוא הצופן המוגדר כברירת מחדל ב-OpenSSH הנוכחי.
7. רק כעת הלקוח מאמת את זהותך, באמצעות סיסמה או מפתח. שם המשתמש והסיסמה שלך עוברים בתוך הערוץ המוצפן.
8. הלקוח פותח ערוץ ומבקש מעטפת (shell).

הסדר ברשימה זו הוא ההבדל המהותי מ-telnet. האימות מתבצע לאחר שהערוץ מוצפן ולאחר שהשרת הוכיח את זהותו, כך שאין רגע שבו הסיסמה שלך חשופה על גבי הרשת.

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

מפתח המארח וההודעה על טביעת האצבע בחיבור הראשון

כאשר openssh-server מותקן, הוא מייצר זוגות מפתחות מארח עבור המכונה וכותב אותם ל-/etc/ssh/, לדוגמה ssh_host_ed25519_key ו-ssh_host_ed25519_key.pub. החלק הפרטי לעולם אינו עוזב את השרת. החלק הציבורי הוא הזהות של השרת, והוא מה שנגדו נבדקת החתימה בשלב 5.

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

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:E9nVQ5Sm2oQ3nGm5Zf1tOaU7Xh0k2p8bWc4dLrTvYxA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

טביעת האצבע היא גיבוב SHA256 של המפתח הציבורי של המארח, המוצג בפורמט base64, כך שהוא קצר מספיק להשוואה בעין. הקלדת yes כותבת את המפתח הזה לתוך ~/.ssh/known_hosts במכונה שלכם. כל חיבור מאוחר יותר לאותה כתובת משווה את המפתח שהשרת מציע מול המפתח השמור. כאשר הם תואמים, לא מודפס דבר ואתם עוברים ישירות לשורת הפקודה שלכם.

מודל זה נקרא "אמון בשימוש ראשון" (trust on first use), וכדאי להיות כנים לגבי המחיר שלו. החיבור הראשון הוא הרגע היחיד שבו אתם לא מוגנים, כיוון שאתם מקבלים מפתח שמעולם לא ראיתם קודם לכן. כדי לסגור את הפער הזה, השיגו את טביעת האצבע בדרך אחרת והשוו אותה. רוב הספקים מדפיסים אותה בפלט האתחול המוצג במסוף הניהול (web console) שלהם, ואתם יכולים גם להדפיס אותה בשרת עצמו:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

פקודה זו מדפיסה את אותה מחרוזת SHA256: שההודעה הציגה לכם. האפשרות [fingerprint] בהודעה קיימת בדיוק עבור זה: הדביקו את טביעת האצבע שאתם מצפים לה, והלקוח ימשיך רק אם היא תואמת למה שהשרת הציג.

ב-Debian וב-Ubuntu, הקובץ known_hosts עובר גיבוב כברירת מחדל, לכן הקובץ מכיל שורות שמתחילות ב-|1| במקום בשמות מארח קריאים. הריצו את ssh-keygen -F 203.0.113.10 כדי למצוא את הרשומה עבור מארח מסוים.

מדוע SSH מציג הודעה על שינוי ב-host key?

במוקדם או במאוחר תיתקלו בקיר הטקסט הבא:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

הוא מסתיים ב-Host key verification failed. והלקוח מסרב להתחבר. הוא גם מדפיס Password authentication is disabled to avoid man-in-the-middle attacks., כיוון שהקלדת סיסמה במכונה לא מוכרת היא בדיוק הנזק שהבדיקה הזו נועדה למנוע.

ההודעה נראית כמו מצב חירום, אך ברוב המקרים אין זה כך. הסיבות הנפוצות הן:

• בניתם מחדש או התקנתם מחדש את השרת, ולכן sshd יצר host keys חדשים בעלייה הראשונה. זוהי הסיבה הנפוצה ביותר בפער ניכר.
• השמדתם שרת VPS אחד ויצרתם אחר, והספק הקצה למכונה החדשה את אותה כתובת IP.
• אתם מתחברים דרך forward או load balancer שמגיע כעת למכונת backend אחרת.
• משהו אכן מבצע יירוט (interception) לחיבור.

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

ssh-keygen -R 203.0.113.10

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

אימות באמצעות סיסמה לעומת אימות באמצעות מפתח

אימות באמצעות סיסמה שולח את הסיסמה שלכם בתוך הערוץ המוצפן ממילא, ו-sshd בודק אותה מול מסד הנתונים של החשבונות, בדרך כלל באמצעות PAM (ר"ת של Pluggable Authentication Modules). שיטה זו אינה דורשת הכנה מוקדמת, וזו הסיבה שספק שירות יכול לספק לכם שרת חדש עם סיסמת root בלבד.

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

אימות באמצעות מפתח ציבורי (Public key authentication) פועל אחרת. אתם יוצרים זוג מפתחות במחשב האישי שלכם. החצי הציבורי מועבר ל-~/.ssh/authorized_keys בתוך החשבון שלכם בשרת. החצי הפרטי נשאר במחשב הנייד שלכם ולעולם אינו מועבר ברשת. כדי להתחבר, הלקוח חותם על פיסת מידע הכוללת את מזהה הסשן מחילופי המפתחות, והשרת מאמת את החתימה באמצעות המפתח הציבורי שכבר נמצא ברשותו. מכיוון שהמידע החתום קשור לסשן ספציפי זה בלבד, חתימה שנתפסה חסרת ערך לכל מטרה אחרת.

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

לאימות באמצעות מפתחות יש מצבי כשל משלו. sshd מתעלם ממפתחות כאשר הרשאות הקבצים רופפות מדי, והוא מדווח על כך בלוג של השרת:

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

הלקוח תמיד יציג לכם רק Permission denied (publickey), הודעה זהה עבור תריסר סיבות שונות, לכן כדאי ללמוד כיצד לקרוא נכון שגיאות של publickey לפני שתינעלו מחוץ למערכת. העבודה המעשית של יצירת מפתחות, הגנה עליהם באמצעות passphrase וטעינתם לתוך סוכן (agent) מפורטת ב-ניהול מפתחות SSH, וביטול האפשרות להתחברות באמצעות סיסמה מבלי להישאר חסומים מפורט ב-הקשחת SSH בשרת VPS.

SFTP, scp והעברת פורטים משתמשים באותו חיבור

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

• Shell מרוחק. ssh you@server פותח ערוץ session ומבקש Shell אינטראקטיבי.
• פקודה בודדת. ssh you@server uptime פותח ערוץ, מריץ פקודה אחת, מדפיס את הפלט ונסגר.
• SFTP. הלקוח מבקש מ-sshd להפעיל את ה-subsystem מסוג sftp, והעברת הקבצים מתבצעת בתוך אותו חיבור. SFTP הוא פרוטוקול להעברת קבצים שרוכב על גבי SSH, ואין לו קשר תכנוני ל-FTP. הפרוטוקול שהוא FTP עם תוספת הצפנה נקרא FTPS, והוא אינו קשור.
• scp. מעתיק קבצים תוך שימוש באותה התחברות. מאז גרסה 9.0 של OpenSSH, ששוחררה ב-2022, scp משתמש כברירת מחדל בפרוטוקול SFTP ברקע.
• העברת פורטים (Port forwarding). ssh -L 8080:localhost:80 you@server הופך את פורט 8080 במחשב הנייד שלכם לפתח גישה לפורט 80 בשרת, כאשר התעבורה עוברת בתוך החיבור המוצפן. -R מבצע העברה בכיוון ההפוך, ו--D 1080 הופך את ה-session ל-SOCKS proxy.
• Git. כתובת מרוחקת כמו git@github.com:user/repo.git היא התחברות SSH שבה הצד המרוחק מריץ מטפל פקודות (command handler) במקום Shell.
• rsync ו-Ansible הם גם לקוחות SSH. הם פותחים ערוץ, מריצים משהו וקוראים את הפלט בחזרה.

כל פריט ברשימה זו משתמש באותו פורט, באותה בדיקת host key ובאותם פרטי אימות. זו הסיבה שהגדרת אימות מבוסס מפתח משתלמת מיד: כל הכלים הללו יורשים את ההגדרה הזו. זו גם הסיבה שקובץ ה-~/.ssh/config, שמקצר את תהליך ההתחברות שלכם, הוא הקובץ שמאפשר לכם להתנהל ביעילות בעת ניהול כמה שרתי Linux ממחשב נייד אחד.

מה SSH אינו עושה

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

צעדים הבאים

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

FAQ

מה המשמעות של ראשי התיבות SSH?

SSH מייצג Secure Shell. זהו פרוטוקול להתחברות למחשב מרוחק והרצת פקודות עליו באמצעות חיבור מוצפן, המוגדר ב־RFC 4251 עד RFC 4254. OpenSSH הוא המימוש שבו כמעט כולם משתמשים: הלקוח ssh במחשב שלך, והשרת sshd במחשב המרוחק. הוא החליף את telnet, ששלח הכל, כולל סיסמאות, ברשת בטקסט גלוי.

מדוע SSH משתמש בפורט 22?

IANA הקצתה את פורט 22 ל־SSH בשנת 1995, לצד FTP בפורט 21 ו־telnet בפורט 23, הפרוטוקולים שאותם נועד להחליף. שום דבר לא מחייב את המספר הזה: Port בתוך /etc/ssh/sshd_config משנה אותו בשרת, ו־ssh -p בוחר פורט אחר בלקוח. מכיוון ש־22 הוא ברירת המחדל, סורקים אוטומטיים דופקים עליו ללא הרף, וזו הסיבה שקובץ ה-/var/log/auth.log של שרת חדש מתמלא בשורות Failed password for invalid user. שינוי הפורט מפחית את הרעש הזה אך אינו מוסיף הגנה של ממש.

מה עליי לעשות כאשר SSH מזהיר שמפתח המארח (host key) השתנה?

מצא את הסיבה לפני שתמחק דבר. הסיבה הרגילה היא לא מזיקה: השרת הוקם מחדש, ולכן sshd יצר מפתחות מארח חדשים, או שמכונה חדשה קיבלה את כתובת ה-IP הישנה. אם ידוע לך שהמכונה הוקמה מחדש, הרץ את ssh-keygen -R <host> כדי להסיר את המפתח השמור, התחבר מחדש, והשווה את ה-fingerprint שמוצג לך לזה שמדווח בקונסולת ספק השרתים שלך. אם שום דבר לא השתנה בצד שלך, אל תתחבר ואל תקליד את הסיסמה שלך. OpenSSH כבר מסרב לאימות סיסמה במצב זה בדיוק מהסיבה הזו.

האם SFTP ו-scp שונים מ-SSH?

הם רצים על גביו. ברגע שעברת אימות, חיבור ה-SSH יכול לשאת כמה ערוצים, ו-shell הוא רק אחד מהם. SFTP הוא פרוטוקול להעברת קבצים המשתמש ב-subsystem של sftp בתוך sshd על גבי אותו חיבור, ו-scp משתמש בפרוטוקול SFTP מתחת למכסה המנוע מאז OpenSSH 9.0. גם העברת פורטים (port forwarding) ו-Git over SSH הם ערוצים על אותו חיבור. כולם משתמשים באותו פורט, באותה בדיקת מפתח מארח ובאותו תהליך התחברות. שים לב ש-SFTP אינו FTP עם הצפנה מוספת; לזה קוראים FTPS וזהו פרוטוקול נפרד.

האם אימות באמצעות מפתח באמת טוב יותר מסיסמה?

כן, עבור כל שרת שנגיש מהאינטרנט. סיסמה היא סוד קצר שאתה מוסר לשרת בכל התחברות, ופורט 22 מותקף בניחושים ללא הרף על ידי לקוחות אוטומטיים. עם זוג מפתחות, החצי הפרטי לעולם לא עוזב את המחשב שלך: הלקוח חותם על נתונים הקשורים לסשן הנוכחי, והשרת בודק את החתימה מול המפתח הציבורי ב-~/.ssh/authorized_keys. לא ניתן להשתמש בחתימה מוקלטת שוב מול שרת אחר. הגן על המפתח הפרטי באמצעות passphrase, כיוון שקובץ מפתח ללא passphrase הוא אמצעי התחברות פעיל לכל מי שיעתיק אותו.