מישהו צריך להיכנס לשרת הלילה, ופרטי ההתחברות צריכים להגיע אליו עכשיו. הפיתוי הוא להדביק את המפתח הפרטי או את סיסמת ה-root ב-Slack. כל הודעה שהמפתח עובר דרכה שומרת עותק, ולכן הדרך הטובה יותר היא קישור חד-פעמי שתוקפו פג: מקבלים את הסוד פעם אחת, ואז הוא נעלם.
אבל הקישור הוא רק שלב המשלוח. לפני שיוצרים אותו, בחרו את פרטי ההתחברות הנכונים לשליחה, הגבילו אותם למשימה והחליטו איך תסירו אותם. המדריך הזה עובר על כל זה, כולל השאלה מה להכניס לקישור חד-פעמי לשיתוף פרטי גישה לשרת ומה להשאיר בחוץ.
אילו פרטי התחברות SSH אתם בעצם משתפים?
גישת SSH יכולה להתבסס על ארבעה דברים שונים, ולכל אחד מהם כללי שיתוף שונים מאוד.
| פרטי התחברות | מה זה | האם הם צריכים לעבור בכלל? |
|---|---|---|
| מפתח ציבורי | החצי שהשרת שומר | כן, בחופשיות. הוא לא סודי. |
| מפתח פרטי | החצי שהמשתמש מחזיק | רק כשהוא נוצר במיוחד לנמען, ורק פעם אחת |
| סיסמה | מחרוזת משותפת שהשרת בודק | פעם אחת, כערך זמני שתחליפו |
| תעודת SSH | מפתח שה-CA שלכם חתם עליו, עם תקופת תוקף | התעודה לא סודית, המפתח שמאחוריה כן |
המסירה הטובה ביותר היא זו שבה שום דבר סודי לא עובר. אם לנמען
כבר יש זוג מפתחות SSH, בקשו ממנו את המפתח הציבורי, הוסיפו אותו
לקובץ ~/.ssh/authorized_keys בחשבון הנכון ואמרו לו להתחבר. הסרת
השורה הזו בהמשך מסיימת את הגישה שלו.
צרו לו מפתח ייעודי כשאין לו מפתח והוא לא יכול ליצור אחד. אף פעם אל תשלחו את המפתח הפרטי שאתם משתמשים בו ביום-יום. מפתח שנוצר לנמען אפשר להגביל, לתעד ולמחוק בלי לגעת בשום דבר אחר.
לצורך חוזר, העדיפו תעודות או גישה מנוהלת. אם אותו אדם יצטרך גישה שוב ושוב, מסירות חד-פעמיות חוזרות הן הכלי הלא נכון. תעודת SSH עם תוקף קצר, או כלי גישה כמו Teleport או Tailscale SSH, נותנים תפוגה שמובנית בפרטי ההתחברות עצמם, ולא מודבקת על שלב המשלוח.
הגבילו את פרטי ההתחברות לפני שאתם משתפים אותם
מה שלא תשלחו, צמצמו אותו ככל שהמשימה מאפשרת:
- חשבון אחד, שרת אחד. הוסיפו את המפתח לחשבון השירות שאחראי על העבודה, לא ל-root, ורק במכונה הרלוונטית.
- הגבילו את מה שהמפתח יכול לעשות באמצעות אפשרויות של
authorized_keysכמוfrom="203.0.113.5",no-port-forwardingאו עטיפתcommand=כשהעבודה היא סקריפט אחד. - תנו לסיסמה תאריך תפוגה. אם אתם משתפים סיסמה, הריצו
passwd -eאו את המקבילה בפלטפורמה שלכם, כדי שהנמען יצטרך להחליף אותה בהתחברות הראשונה, ותכננו להשבית את החשבון בתאריך קבוע. - רשמו את תאריך הסיום לפני שאתם שולחים משהו. "כשהעבודה תיגמר" זה לא תאריך.
איך משתפים פרטי התחברות SSH בקישור שתוקפו פג
- ודאו מי הנמען בערוץ שאתם כבר סומכים עליו: כרטיס התמיכה, שרשור אימייל מוכר או שיחה. רוב פרטי ההתחברות שמגיעים לאדם הלא נכון נשלחים לכתובת שנראית דומה או לשם שהושלם אוטומטית.
- הדביקו רק את הסוד בכלי ליצירת קישורים סודיים חד-פעמיים. במפתח פרטי הכוונה לכל בלוק ה-PEM ולשום דבר אחר. ב-LinkPilot הטקסט מוצפן בדפדפן שלכם לפני שהוא נשמר, כך שהשירות מחזיק תמיד רק טקסט מוצפן, ומפתח הפענוח נמצא בחלק של הכתובת שדפדפנים לא שולחים לשרתים.
- התאימו את התפוגה לחלון הזמן. שעה אחת אם הנמען מחכה לקישור, 24 שעות אם הוא באזור זמן אחר, שבעה ימים רק כשיש סיבה אמיתית. הקישור גם מושמד בפעם הראשונה שפותחים אותו, כך שהתפוגה היא רשת הביטחון, ולא אמצעי הבקרה העיקרי.
- הוסיפו ביטוי סיסמה בחשבון Pro כשפרטי ההתחברות רגישים, ומסרו את ביטוי הסיסמה בערוץ אחר. ב-Pro יש גם יומן ביקורת שמראה מתי הסוד הוצג.
- שלחו את הקישור עם שורה אחת שמסבירה למה הוא מיועד, ובלי פרטי חיבור.
- שלחו את פרטי החיבור בהודעה נפרדת: שם השרת או הכתובת, הפורט, שם המשתמש ושיטת האימות. אף אחד מהם לא סודי לבדו, אבל יחד עם המפתח הם כל פרטי ההתחברות.
אם הקישור מציין שכבר פתחו אותו והנמען אומר שהוא לא פתח אותו, אל תתווכחו על זה. התייחסו לפרטי ההתחברות כאל חשופים, הסירו את המפתח או החליפו את הסיסמה, וצרו חדשים.
קישור חד-פעמי לשיתוף פרטי גישה לשרת
השאלה מה שייך לתוך הסוד עולה כל פעם מחדש. כלל טוב: הקישור נושא את מה שתוקף לא יכול לנחש, וההודעה הרגילה נושאת את מה שהוא כן יכול.
בקישור החד-פעמי:
- המפתח הפרטי, או הסיסמה הזמנית
- ביטוי סיסמה למפתח, אם הוגדר כזה כשהמפתח נוצר
- שום דבר אחר
בהודעה רגילה, שנשלחת בנפרד:
- שם המארח או כתובת ה-IP, והפורט
- החשבון שאליו מתחברים
- האם להשתמש במפתח או בסיסמה
- טביעת האצבע של מפתח השרת, כדי שהנמען יוכל לאמת את השרת בחיבור הראשון
- הערה קצרה: למה הגישה מיועדת ומתי היא מסתיימת
השאירו צילומי מסך ולוגים של הטרמינל מחוץ לשניהם. צילום מסך של עבודה בטרמינל כולל לעיתים קרובות טוקנים, כתובות פנימיות ושמות משתמש אחרים שאף פעם לא היו אמורים לעבור.
עזרו לנמען לשמור את המפתח בבטחה
מסירה מאובטחת עדיין נכשלת אם המפתח נשמר בתיקיית ההורדות עם הרשאות קריאה לכולם. שלחו את ההוראות האלה יחד עם פרטי החיבור:
# save the key, then lock it down
chmod 600 ~/.ssh/acme_deploy
ssh-add ~/.ssh/acme_deploy
# verify the host key fingerprint against the one you were sent
ssh -i ~/.ssh/acme_deploy deploy@203.0.113.5
בקשו מהנמען לפתוח את הקישור הסודי רק כשהוא מוכן להשתמש בו, במכשיר שבשליטתו ובחיבור שהוא סומך עליו. פתיחה במחשב משותף "רק כדי לבדוק שזה עובד" משאירה עותק בהיסטוריית לוח ההעתקה של אותו מחשב.
בדקו, ואז סגרו את החלון
כל עוד חלון הגישה פתוח, בקשו מהנמען לבדוק את החיבור המדויק ולוודא שהמשימה רצה. אל תרחיבו הרשאות כדי שבדיקה תעבור; תקנו את ההגבלה במקום זה.
כשהעבודה מסתיימת:
- הסירו את המפתח הציבורי מ-
authorized_keys, או השביתו את החשבון, או תנו לתעודה לפוג בזמן שנקבע. - החליפו כל מה שעבר יחד עם פרטי ההתחברות, כולל סיסמה זמנית שהייתה אמורה להשתנות בהתחברות הראשונה ולא השתנתה.
- עברו על
auth.logאו על מקור הביקורת של SSH, וחפשו חיבורים מחוץ לזמן המוסכם או מכתובות לא צפויות. - רשמו למי היה מה, ממתי ועד מתי. התיעוד נשאר; פרטי ההתחברות לא.
התפוגה של הקישור מגבילה כמה זמן אפשר היה לקבל את הסוד. התפוגה של פרטי ההתחברות מגבילה כמה זמן אפשר להשתמש בהם. צריך את שתיהן, ואת השנייה אנשים שוכחים.