OpenVPN PAM: ארגומנט הכניסה הוא שם שירות, לא שם משתמש

משתמש נוסף לשרת, הסיסמה הוקלדה נכון, והחיבור עדיין מסתיים ב-AUTH_FAILED. שורת התוסף בדרך כלל מסבירה למה: המילה שאחרי נתיב התוסף היא שם שירות PAM, והיא קובעת איזו מחסנית של מודולים עונה לשאלה. זה אינו שם משתמש, וזה אינו מצביע לקובץ סיסמאות ש OpenVPN קורא בעצמו.

מה המילה השנייה בוחרת

שורת התצורה לוקחת נתיב תוסף וארגומנט אחד:

plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

הארגומנט הזה מועבר לספריית PAM כשם השירות, וזה מה שמפעיל את המחסנית ב-/etc/pam.d/openvpn. אם תכתבו שם login, תקבלו במקום זאת את מדיניות הכניסה האינטראקטיבית, עם המודולים שמדיניות זו כוללת בהפצה שלכם.

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

מאיזה מקום המחסנית באמת קוראת חשבונות

PAM הוא מפזר. קובץ השירות מפרט מודולים לפי סדר, והראשון שיכול לענות קובע את התוצאה. מחסנית שקוראת ל-pam_unix קוראת חשבונות מקומיים; מחסנית שקוראת למודול LDAP או RADIUS שולחת את פרטי הכניסה למקום אחר לגמרי.

קראו את הקובץ שאליו מתפרש שם השירות, כולל כל מה שהוא כולל:

cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-auth

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

ניסיון אחד, שני יומנים

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

journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"

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

pamtester openvpn alice authenticate

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

שירות ייעודי עדיף על עריכת הכניסה

תנו ל-VPN קובץ שירות משל עצמו כאשר הדרישות שלו שונות מכניסה אינטראקטיבית, וזה בדרך כלל המצב. עריכת login או common-auth משנה את המדיניות לכל תוכנית שמכלילה אותם, והאדם הבא שינפה באגים בבעיית כניסה לא קשורה יירש את השינוי שלכם.

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

מה הלקוח שולח, ומה הוא לא

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

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

הקבלה היא דו-כיוונית: החשבון המיועד מצליח, וחשבון שאמור להידחות עדיין נכשל. הקובץ README של התוסף auth-pam מתעד את ארגומנט השירות ואת ה-backend-ים שהוא יכול לשרת, ושם המקום לאשר את הסידור שאתם מנסים לבנות.