אימות SSH באמצעות מפתחות: הגדרת גישה ללא סיסמאות

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

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

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

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

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

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

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

מה משתנה לאחר המעבר לאימות במפתחות

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

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

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

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

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

אפשרויות גישה: מפתחות SSH, סיסמאות ותעודות

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

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

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

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

כיצד מתבצעת הטמעת גישת מפתח בתשתית

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

1. ביקורת גישה לשרתים: אוספים רשימה של מארחים, חשבונות, מקורות התחברות ו-authorized_keys נוכחיים עם טביעות אצבע. מסמנים בנפרד מפתחות משותפים, כניסה כ-root ורשומות שאיש אינו יכול לאשר.
2. תכנון מודל הגישה: תפקידים (מנהל, פריסה, קריאת יומנים), מפתח נפרד לכל תפקיד ולכל אדם, צומת באסטיון אחוד לחיבורים חיצוניים במקום פורטים ישירים בכל שרת.
3. יצירה ואחסון של מפתחות: אלגוריתם חתימה מודרני, ביטוי סיסמה על החלק הפרטי, המפתח הפרטי — רק במאגר מוגן, ולמרשם נכנסים החלקים הציבוריים וטביעות האצבע.
4. פריסת מפתחות ציבוריים ותצורה: authorized_keys דרך תבניות וניהול תצורה, וב-sshd_config — השבתת סיסמאות וכניסת root, הגבלת אלגוריתמים ומספר החיבורים. מיישמים בלי להפעיל מחדש שירותים פעילים.
5. בדיקת הגדרת הגישה: כניסת ניסיון בכל תפקיד, בדיקת שלילת מפתח ותגובת היומנים, בקרה שדרכי הכניסה הישנות סגורות, אך ערוץ החירום זמין לתורן.
6. מסירת מפתחות לצוות: הפצה בערוץ מוגן, ssh_config מוכן עם כינויים ובאסטיון, נוהל סבב החלפה ושלילה, הנחיה קצרה למהנדסים חדשים.
7. נוהל ותחזוקה: תוקף המפתחות, סבב החלפה מתוכנן, רשימת בדיקה בעת החלפת תפקיד או עזיבת עובד, מרשם טביעות האצבע כמקור האמת.

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

מה נשאר לכם לאחר הגדרת הגישה

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

• תצורות השרתים — sshd_config עם אימות סיסמה מושבת, הגבלה לפי משתמשים וקבוצות, מגבלת ניסיונות וזמן קצוב לחיבור, בצורה הניתנת להעברה למערכת ניהול התצורה.
• תרשים גישת המפתח — אילו מפתחות SSH מובילים לאן, היכן נשמרים החלקים הפרטיים, אילו צמתים פתוחים ישירות ואילו זמינים רק דרך מארח מתווך.
• נוהל הנפקת מפתחות — מי יוזם את הבקשה, כיצד נוצר הזוג, היכן חי המפתח הפרטי, מה נרשם בבקשה ומי מאשר את ההנפקה.
• נוהל שלילה — המועד למחיקת הרשומה מ-authorized_keys, סדר הפעולות בעת פיטורים והחלפת תפקיד, בדיקה שהמפתח הקודם אינו מעניק עוד גישה.
• תיעוד לתורנות — תסמינים אופייניים (כשל אימות, הרשאות שגויות על הספרייה, הצפת יומן), מה לבדוק קודם לכן ולמי לפנות בעת תקלה.
• סקר מלאי של גישות — טבלת «עובד — מפתח — שרת — תוקף», שממנה רואים למי יש גישה ומתי היא אמורה להסתיים.
• נקודות ניטור — אילו אירועים נכתבים ליומן (ניסיונות מוצלחים וכושלים, שינוי בהרכב המפתחות), לאן הם נשלחים ובאיזה סף מופעלת התראה.

מקרה בוחן: כיצד סגרו כניסה בסיסמה בצוות מפוזר

לפני: 140 שרתים וסיסמאות בשלושה מקומות

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

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

אחרי: מפתח אישי וחתימה קצרה

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

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

מה השתנה

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

מה לעשות אם כניסה בסיסמה פרוסה בכל השרתים

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

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

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

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

ספקות ומגבלות לפני הגדרת הגישה

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

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

כיצד להנפיק גישה לחשבונות שירות ולאוטומציה?

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

ומה אם חלק מהמערכות אינן תומכות במפתחות?

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

כל כמה זמן להחליף מפתחות ומי שולט בכך?

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

נדון בגישה לשרתים בלי סיסמאות

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

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

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