איך לנהל מפתחות SSH בצורה נכונה

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

מפתח SSH מורכב מזוג קבצים: מפתח פרטי (private key) שנשאר על המכשיר שלך, ומפתח ציבורי (public key) שאתה מעתיק לכל שרת שברצונך להתחבר אליו. בזמן החיבור, השרת משתמש במפתח הציבורי כדי לשלוח "אתגר" (challenge) שרק המפתח הפרטי המתאים יכול לענות עליו. המפתח הפרטי לעולם אינו עוזב את המכשיר שלך, ולכן שום מידע סודי לא עובר ברשת. גם אם שרת נפרץ, אין לו דבר מועיל לגנוב. זו הסיבה שמפתחות עדיפים על סיסמאות. ניהול נכון של מפתחות SSH מתבסס על ארבע הרגלים: מפתח אחד לכל מכשיר, הרשאות הקובץ הנדרשות על ידי sshd, קובץ ~/.ssh/config כדי למנוע הקלדת אפשרויות (options) בכל פעם, וידיעה כיצד להסיר מפתח ברגע שמחשב נייד אובד.

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

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

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

במחשב האישי שלך, ולא בשרת, הרץ:

ssh-keygen -t ed25519 -C "laptop"

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

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

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

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

מפתח אחד לכל מכשיר, לא אחד לכל שרת

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

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

עם מפתח אחד לכל מכשיר, המחשב הנייד האבוד עולה לך רק שורה אחת בכל שרת: מחק את השורה של המחשב הנייד מתוך 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 של הספק שלך, והרצץ את הפקודה הבאה בשרת:

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

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

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

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

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

ב-image מינימלי ללא 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 על כל מה שבתוכה. אותם מספרים תקפים גם במחשב האישי שלך, כיוון שגם ה-client מבצע בדיקה. מפתח פרטי שניתן לקריאה על ידי משתמשים אחרים גורם ל-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 שלך מחזיק מספר מפתחות, ה-client מציע אותם אחד אחד, והשרת סופר כל הצעה כניסוי כושל. עם מספיק מפתחות טעונים, תקבל Received disconnect: Too many authentication failures לפני שהמפתח הנכון ייבדק. IdentitiesOnly yes גורם ל-client להציע רק את המפתח שצוין ב-IdentityFile, כך השגיאה לא יכולה להתרחש.

Passphrases ו-ssh-agent

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

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

ssh-add ~/.ssh/id_ed25519

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

Rotation וביטול: תרגיל המחשבון האבוד

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

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

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

לאחר מכן, ודאו מהמכשיר שביטלתם שנית ההתחברות נכשלה, וממכשיר אחר שנית ההתחברות עדיין עובדת. שימו לב לפרט אחד: הסרת מפתח אינה סוגרת סשנים (sessions) שפתוחים بالفعل, כיוון שהמפתח נבדק רק בזמן ההתחברות. אם אתם מבטלים מכשיר שנגנב, בדקו גם את who בשרת וסגרו כל סשן שאינו מוכר לכם.

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

מה לא לעשות

• אל תשתמש במפתח פרטי אחד בכל המכשירים שלך. במצב זה, לא ניתן לבטל את הגישה של מכשיר אחד שנגנב מבלי להחליף את המפתח בכל שאר המכשירים.

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

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

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

לאחר שהמפתח מאפשר לך התחברות אמינה, בצע את הצעד הבא וכבה את אימות הסיסמה (password authentication), כדי שניסיונות ניחוש מתמשכים נגד השרת שלך לא יצליחו. ההגדרות המתאימות לכך נמצאות ב-SSH hardening on a VPS.

FAQ

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

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

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

שימוש במפתח אחד עבור שרתים רבים הוא נכון, כל עוד המפתח נשאר על מכשיר واحد. הכלל הוא מפתח אחד לכל מכשיר, ולא מפתח אחד לכל שרת: המפתח הציבורי של הלפטופ שלך צריך להימצא בכל שרת שהלפטופ זקוק לו, ולמחשב השולחני יהיה מפתח משלו. זה הופך את ביטול המפתח (revocation) לפשוט, מכיוון שאיבוד מכשיר פירושו הסרת שורה אחת מזהה מכל שרת, והמכשירים האחרים ימשיכו לעבוד.

אילו הרשאות צריבות להיות לתיקיית .ssh ול-authorized_keys?

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

איך מסירים מפתח SSH משרת?

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

האם אני צריך passphrase על מפתח ה-SSH שלי?

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