תיקון: OpenVPN לא הצליח לקרוא את שם המשתמש של Auth מקלט התקני

could not read Auth username from stdin נראה כמו בעיית אימות וזה לא. OpenVPN ניסה לבקש את שם המשתמש מקלט תקני, לא מצא דבר קריא ועצר לפני שיצר קשר עם השרת. החשבון יכול להיות תקף לחלוטין; פשוט אין לתהליך את מי לשאול.

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

קראו את השגיאה ככשל קלט מקומי

כאשר auth-user-pass מופיע בלי ארגומנט קובץ, הלקוח מצפה לשאול. במעטפת אינטראקטיבית ההנחיה הזאת עובדת כי לתהליך יש מסוף. תחת systemd, משימת cron או מכולה, הקלט התקני בדרך כלל ריק, והקריאה חוזרת מיד עם השגיאה שאתם רואים.

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

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

תנו לשירות מקור אסימונים נתמך

המקור הנתמך להפעלה ללא השגחה הוא קובץ אסימונים שמועבר כארגומנט אל auth-user-pass. הקובץ נקרא כטקסט פשוט: השורה הראשונה היא שם המשתמש, השנייה היא הסיסמה. הצביעו עליו בנתיב מוחלט כמו /etc/openvpn/client/creds , כדי שספריית העבודה של חשבון השירות לא תוכל לשנות את משמעות ההוראה.

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

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

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

למה script-security לא יעזור

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

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

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

אמתו את השלב הבא אחרי שהלקוח קרא את הקובץ

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

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

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

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