ניהול מפתחות SSH: מדריך מעשי ואבטחה

כיצד פועלים מפתחות SSH

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

מדריך זה מכסה כל הרגל על Ubuntu 24.04, אם כי כמעט כל מה שמופיע כאן תקף לכל שרת Linux ולכל גרסה עדכנית של OpenSSH.

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

יצירת מפתח: ed25519 היא ברירת המחדל המומלצת

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

ssh-keygen -t ed25519 -C "laptop"

הדגל -t ed25519 קובע את סוג המפתח. Ed25519 היא ברירת המחדל המודרנית: המפתחות קצרים, מהירים ונתמכים בכל גרסה של OpenSSH מאז 2014. השתמשו ב-ssh-keygen -t rsa -b 4096 רק כאשר עליכם לתקשר עם התקן ישן שאינו תומך ב-ed25519. הדגל -C "laptop" מגדיר הערה. להערה אין משמעות קריפטוגרפית, אך היא תאפשר לכם לזהות את המפתח בקובץ ה-authorized_keys של השרת בעוד שנתיים, לכן מומלץ לתת שם למכשיר שבו המפתח מאוחסן.

הפקודה ssh-keygen תבקש מכם לציין היכן לשמור את המפתח. קבלו את ברירת המחדל, ~/.ssh/id_ed25519. לאחר מכן תתבקשו להזין סיסמה (passphrase). הגדירו אחת; סעיף הסיסמאות להלן מסביר מדוע היא אינה גובה מכם מחיר בשימוש יומיומי. בסיום התהליך ייווצרו שני קבצים: ~/.ssh/id_ed25519 הוא המפתח הפרטי, ו-~/.ssh/id_ed25519.pub הוא המפתח הציבורי. הציגו את החלק הציבורי:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

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

מפתח אחד לכל התקן, לא מפתח אחד לכל שרת

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

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

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

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

הצבת מפתח ציבורי בשרת

הדרך הפשוטה ביותר היא שימוש ב-ssh-copy-id, שמגיע כחלק מ-OpenSSH:

ssh-copy-id matt@10.0.0.10

הפקודה מתחברת באמצעות שיטת האימות הזמינה (בדרך כלל סיסמה), מצרפת את המפתח הציבורי שלכם לקובץ ~/.ssh/authorized_keys בשרת, ויוצרת את התיקייה והקובץ עם הרשאות מתאימות אם הם חסרים. בצעו בדיקה על ידי פתיחת session חדש של SSH: השרת אמור לאפשר לכם להיכנס ללא בקשת סיסמת המשתמש. אם למפתח שלכם יש passphrase, ייתכן שהמחשב המקומי שלכם יבקש אותו; בקשה זו היא מקומית ואינה הסיסמה של השרת.

כאשר הכניסה באמצעות סיסמה כבר מנוטרלת, ssh-copy-id לא יוכל להתחבר, ולכן עליכם להוסיף את השורה ידנית. התחברו דרך session שעדיין פעיל, או דרך ה-web console של ספק השרת, והריצו את הפקודה הבאה בשרת:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

הדביקו את המפתח הציבורי האמיתי שלכם בתוך המירכאות, כשורה אחת מלאה מתוך id_ed25519.pub. הקובץ authorized_keys מכיל מפתח ציבורי אחד בכל שורה, וזהו כל בסיס הנתונים של הגישה: הוספת מכשיר מתבצעת על ידי הוספת שורה, וביטול גישה של מכשיר מתבצע על ידי מחיקת השורה שלו. בשרת חדש, שלב זה שייך ל-עשר הדקות הראשונות ב-VPS חדש, ממש לפני שאתם מכבים את האפשרות להתחבר באמצעות סיסמה.

הרשאות שגורמות לכשל בהתחברות באמצעות מפתח

זוהי הסיבה הנפוצה ביותר לכשל בהתחברות באמצעות מפתח, והיא מתרחשת ללא חיווי למשתמש בצד הלקוח. שירות sshd פועל כברירת מחדל עם StrictModes yes בגרסת Ubuntu 24.04, מה שאומר שהוא מסרב להשתמש בקובץ authorized_keys שמשתמשים אחרים יכולים לערוך. אם הקובץ, ספריית ה-~/.ssh, או ספריית הבית שלכם ניתנים לכתיבה על ידי מישהו מלבדכם, sshd יתעלם מהמפתח שלכם ויחזור לבקש סיסמה, ללא הסבר בצד הלקוח. (גרסת ה-OpenSSH של Ubuntu מאפשרת מקרה חריג אחד בלבד: קובץ שניתן לכתיבה על ידי הקבוצה הפרטית שלכם, בתנאי שאף אחד אחר אינו חבר בה. אל תסתמכו על כך; שמרו על ההרשאות המפורטות להלן). הסיבה מופיעה רק בלוג של השרת:

sudo grep 'Authentication refused' /var/log/auth.log

בתמונת מערכת מינימלית ללא rsyslog, לא קיים הקובץ auth.log; אותה שורה מופיעה ב-journal: sudo journalctl -u ssh | grep 'Authentication refused'.

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

התיקון כולל שני שינויי הרשאות ובדיקת בעלות, שיש להריץ בשרת כמשתמש המושפע:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

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

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

הפקודה chmod 600 ~/.ssh/id_ed25519 תפתור זאת.

~/.ssh/config: הפסיקו להקליד אפשרויות

קובץ ~/.ssh/config במחשב האישי שלכם מאפשר להעניק לכל שרת שם קצר ולשמור את האפשרויות שאתם מקלידים שוב ושוב. צרו אותו עם הרשאות 600 והוסיפו בלוק Host עבור כל שרת:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

כעת ssh web1 מחליף את ssh -p 22 matt@10.0.0.10, ואותו שם קצר עובד ב-scp, ב-rsync וב-git, כיוון שכולם קוראים קובץ זה. HostName הוא הכתובת האמיתית, User חוסך לכם את הקלדת שם המשתמש, ו-IdentityFile קובע איזה מפתח יוצע לשרת.

IdentitiesOnly yes ראוי למשפט נפרד, כיוון שהוא פותר כשל מבלבל. כאשר ה-agent שלכם מחזיק כמה מפתחות, הלקוח מציע אותם אחד אחד, והשרת סופר כל הצעה כניסיון כושל. עם מספיק מפתחות טעונים, תקבלו Received disconnect: Too many authentication failures לפני שהמפתח הנכון ינוסה. IdentitiesOnly yes גורם ללקוח להציע רק את המפתח שצוין ב-IdentityFile, כך שהכשל הזה לא יכול לקרות.

ביטויי סיסמה (Passphrases) ו-ssh-agent

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

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

ssh-add ~/.ssh/id_ed25519

הפקודה ssh-add -l מציגה את המפתחות שה-agent מחזיק כרגע. אזהרה אחת: העברת סוכן (agent forwarding, ssh -A) מאפשרת לשרת המרוחק להשתמש ב-agent שלך כדי לבצע אימות הלאה בזמן שאתה מחובר, לכן יש להפעיל אפשרות זו רק מול שרתים שאתה נותן בהם אמון מלא, ולהשאיר אותה כבויה כברירת מחדל.

סבב מפתחות וביטולם: תרגול למקרה של אובדן מחשב נייד

ביטול של מפתח SSH רגיל מסתכם בהסרת השורה שלו מתוך authorized_keys בכל שרת שבו הוא מופיע. אין רשות מאשרת (CA) שיש להודיע לה ואין תאריך תפוגה להמתין לו. ברגע שהשורה הוסרה, התחברות חדשה באמצעות מפתח זה תיכשל.

בצעו את התרגול כעת, כל עוד לא מדובר במצב חירום. בחרו שרת, פתחו את ~/.ssh/authorized_keys, ואתרו את המפתח לפי ההערה (comment) שלו. מחקו את השורה באמצעות עורך טקסט, או סננו אותה לפי ההערה:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

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

סבב מפתחות (Rotation) הוא אותה פעולה בסדר שונה: צרו מפתח חדש במכשיר, התקינו אותו בעזרת ssh-copy-id, ודאו שהמפתח החדש מאפשר התחברות, ורק אז מחקו את השורה הישנה. בצעו זאת כאשר מכשיר מחליף ידיים, כאשר קיים חשש לחשיפת מפתח, או כאשר עובד עוזב את הצוות. ביצוע פעולה זו ידנית בשני שרתים הוא תקין; עבור עשרים שרתים זו כבר משימה לאוטומציה, והמדריך ניהול שרתי Linux מרובים מראה כיצד להפיץ את אותו מצב של authorized_keys לצי שרתים שלם.

מה לא לעשות

• אל תשתמשו באותו מפתח פרטי עבור כל המכשירים שלכם. הדבר הופך את ביטול הגישה של מכשיר גנוב בודד לבלתי אפשרי ללא החלפת המפתח בכל המקומות.

• אל תבצעו commit למפתח פרטי לתוך מאגר git, גם אם מדובר במאגר פרטי. סורקים אוטומטיים מנטרים מאגרים ציבוריים ומנסים להשתמש במפתחות שדלפו תוך דקות מרגע ה-push, ומאגר שיהפוך לציבורי בעתיד יחשוף את כל ההיסטוריה שלו.

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

• אל תדביקו מפתח פרטי בצ'אט, בדואר אלקטרוני או בכרטיס תמיכה. המפתח הציבורי, קובץ ה-.pub, הוא החלק היחיד שניתן לשתף.

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

FAQ

כיצד פועלים מפתחות SSH ללא שליחת סיסמה?

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

האם עליי להשתמש באותו מפתח SSH לכל השרתים שלי?

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

אילו הרשאות צריכות להיות לספריית .ssh ולקובץ authorized_keys?

הגדירו 700 עבור ~/.ssh ו-600 עבור authorized_keys וכל מפתח פרטי, בבעלות החשבון שמשתמש בהם. שירות sshd פועל כברירת מחדל עם StrictModes yes, לכן קובץ או ספריית בית שניתנים לכתיבה על ידי מישהו מלבדך יגרמו לשירות להתעלם מהמפתח שלך בשקט. העקבות היחידים לכך יופיעו כ-Authentication refused: bad ownership or modes ביומן האימות או ב-journal של השרת.

כיצד מסירים מפתח SSH משרת?

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

האם עליי להשתמש בסיסמת passphrase למפתח ה-SSH שלי?

עבור מפתח שנמצא במחשב נייד או נייח, התשובה היא כן. ה-passphrase מצפין את קובץ המפתח, כך שעותק גנוב או מודלף הוא חסר תועלת כשלעצמו, ושימוש ב-ssh-agent מאפשר להקליד אותה פעם אחת בלבד לכל סשן במקום בכל התחברות. מפתחות המשמשים לאוטומציה ללא השגחה בשרת בדרך כלל אינם כוללים passphrase, כיוון שאין אדם נוכח להקליד אותה; במקרים אלו, הגנו על המפתחות על ידי הגבלת ההרשאות של חשבון היעד.