שירות OpenVPN נתקע בביקוש סיסמת המפתח הפרטי: כך מתקנים
לשירות אין מסוף, ולכן מפתח מוצפן זקוק ל-askpass ולקובץ קריא. הפרידו בין סיסמת המפתח לבין הכניסה לשרת ובדקו את היחידה.
OpenVPN מבקש את סיסמת המפתח הפרטי במחשב המקומי, ולכן קובץ כניסה תקין לעולם לא עונה לו. בשירות אין מסוף להקליד בו, וההפעלה או נתקעת או נכשלת עם רשומה ביומן שמציינת את הקלט ולא את הסיבה. שני סודות מעורבים כאן, וכל אחד צריך מקור קריא משלו לפני שהיחידה מופעלת מחדש. המהלך שלמטה מפריד ביניהם, ואז בודק את הזהות שפותחת בפועל כל קובץ.
הבחינו בין שתי הבקשות
סיסמת המפתח מפענחת את המפתח הפרטי המקומי; פרטי החשבון מאמתים את החיבור לשרת. הם מגיעים ממקומות שונים, נכשלים ברגעים שונים ומפיקים הודעות שונות. ערבוב ביניהם שולח אנשים לחפש איפוס סיסמה כשהחשבון כלל לא היה מעורב. קראו את טקסט הבקשה לפני שינוי אפשרות כלשהי, כי הניסוח הוא הרמז האמין היחיד לאיזה סוד חסר.
ב-Community OpenVPN 2.x askpass מציין קובץ שמחזיק את סיסמת המפתח בשורה הראשונה, ו-auth-user-pass מציין קובץ שבו שם המשתמש בשורה אחת והסיסמה בשורה הבאה. אף אחד מהקבצים אינו מספק את האפשרות השנייה. אפליקציית שולחן עבודה או פרופיל NetworkManager עשויים לשמור את שניהם במאגר הסודות שלהם, שלקוח שורת פקודה לעולם לא קורא, לכן שימו לב איזה לקוח אתם מגדירים לפני שכותבים נתיב כלשהו.
כוונו את שתי האפשרויות לקבצים קריאים
פרופיל שזקוק לשתי הקלטות מגיע לבסוף ל-שלוש הפניות לקבצים: המפתח המוצפן, הסיסמה שפותחת אותו וזוג הכניסה. הוסיפו אותם בלי לגעת ב-CA או בבדיקות הזהות, כי אלה קובעות מי השרת ואינן חלק מהבעיה הזו. אם הפריסה אינה משתמשת כלל בפרטי חשבון, הוספת auth-user-pass יוצרת קלט שאיש אינו יכול לספק.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authאפשרויות ללא ארגומנט מתנהגות אחרת מאפשרויות עם נתיב, וההבדל חשוב בשירות. askpass ללא ארגומנט עדיין קורא מהקונסולה, וקובץ auth-user-pass שמכיל רק שם משתמש עדיין משאיר בקשת סיסמה ממתינה. מרגע שהלקוח עובר לדמון הוא אינו יכול לבקש קלט מהמסוף כלל, ולכן שירות שהוגדר כך לא עולה.
נתיבים מוחלטים מסירים את שאלת תיקיית העבודה אך אינם מעניקים גישה. הבעלות, ההרשאה והמעבר מגיעים אחר כך, וכל השלושה נבדקים מול החשבון שהתהליך רץ תחתיו.
קראו את הגדרות היחידה לפני הפרופיל
היחידה, ולא הקובץ שערכתם, קובעת איזו תצורה המופע טוען. קראו את שורת הפקודה שלה וכל drop-in, ואז עקבו אחרי תיקיית העבודה אל הפרופיל שבאמת בשימוש. הפניה לסיסמה שהוספה לקובץ .ovpn אחר לא משנה דבר עבור המופע הזה.
שלוש פקודות לקריאה בלבד עונות על רוב זה. הראשונה מדפיסה את היחידה וכל drop-in, השנייה את הזהות והגדרות ה-sandbox שתוחמות את התהליך, והשלישית מה ההפעלה האחרונה באמת התלוננה עליו. השתמשו בשם המופע שקיים במארח:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bשימו לב ל-ProtectHome ולאפשרויות של הפרופיל עצמו: user, group ו-chroot. קובץ תחת תיקיית בית עשוי להיות קריא ב-shell שלכם ובלתי נראה בתוך השירות לאחר שתיקיות הבית מוסתרות. החשבון ש-systemd מתחיל איתו אינו תמיד החשבון שפותח בסוף את המפתח.
הוכיחו שזהות הריצה יכולה לפתוח את שני הקבצים
קריאת ההרשאה אינה מספיקה, כי כל תיקייה בנתיב חייבת להיות ניתנת למעבר על ידי אותה זהות. עברו על הנתיב רכיב אחר רכיב, ואז בדקו את הפתיחה כחשבון שהתהליך משתמש בו. קובץ בהרשאת 600 בבעלות root עובד רק כל עוד התהליך הוא root, וזה אינו נכון אחרי הורדת ההרשאות שרבים מהפרופילים מבצעים. שתי פקודות מכסות את המעבר ואת הפתיחה:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableהפקודה הראשונה מדפיסה את ההרשאה של כל רכיב ונכשלת במקום שבו החשבון אינו יכול לעבור; השנייה עונה על השאלה היחידה שחשובה, כלומר אם זהות הריצה יכולה לפתוח את הקובץ לקריאה. אף אחת מהן אינה מדפיסה את תוכן הקובץ, וזה בדיוק העניין כשהקובץ מחזיק סיסמה. חזרו על הבדיקה עבור קובץ הכניסה, כי השניים נשמרים לעתים קרובות בבעלות שונה.
אם התהליך משתמש ב-chroot או ב-namespace מוגבל, הריצו את אותה בדיקה מתוך התצוגה הזו, אחרת התשובה מתארת מערכת קבצים שגויה. סיסמה שנשמרה תחת תיקיית בית מוסתרת היא הדוגמה הרגילה לבדיקה שעוברת מחוץ ליחידה ונכשלת בתוכה.
בדקו את ההפעלה הראשונה, ואז חיבור מחדש
הפעילו את המופע פעם אחת וקראו את הכשל הראשון ולא את האחרון. קובץ קלט חסר, פענוח מפתח שנכשל ו-AUTH_FAILED מהשרת הם שלושה אירועים שונים עם שלושה תיקונים שונים. תיקון אזהרת הרשאות אינו מוכיח דבר בשאלה אם המפתח נפתח.
שורת היומן אומרת איזה משלושת המצבים יש לכם. התיקון נובע מכך איזה קלט נכשל:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
אחר כך בדקו את מחזור החיים שבאמת נחוץ לכם: הפעלה בעלייה וכל חיבור מחדש נתמך, ולא רק הפעלה ידנית מה-shell שלכם. עם auth-nocache הקלט נזרק אחרי השימוש הראשון, ולכן חיבור מחדש מאוחר יותר עדיין זקוק למקור קריא. מחזיק מפתחות שנפתח בכניסה לשולחן העבודה אינו זמין לשירות שהתחיל לפני שמישהו נכנס, וזו הסיבה הרגילה לכך שבדיקה ידנית עוברת והפעלה מחדש נכשלת. אם ההפעלה הראשונה מצליחה וחיבור מחדש מאוחר נכשל, קראו ביומן את אירוע החיבור מחדש לפני ששוב משנים הרשאות.
שמירת הסיסמה לצד המפתח מחלישה את מה שההצפנה נותנת, לכן הגבילו את הקובץ ואת הגיבויים שלו. התייחסו להסרת סיסמת המפתח כהחלטת הרשאות נפרדת ולא כתיקון לקלט חסר. פריסה שתלויה באישור אנושי או ב-MFA אינטראקטיבי זקוקה לסוכן או לאינטגרציית ניהול נתמכים; קוד חד-פעמי שנשמר לתמיד אינו תחליף שקול.