บริการ OpenVPN ค้างที่การขอรหัสผ่านคีย์ส่วนตัว: วิธีแก้ไข
บริการไม่มีเทอร์มินัล ดังนั้นคีย์ที่เข้ารหัสต้องมี askpass และไฟล์ที่อ่านได้ แยกวลีรหัสผ่านของคีย์ออกจากการเข้าสู่ระบบเซิร์ฟเวอร์และตรวจสอบ unit
OpenVPN ขอวลีรหัสผ่านของคีย์ส่วนตัวบนเครื่องท้องถิ่น ดังนั้นไฟล์เข้าสู่ระบบที่ใช้งานได้จึงไม่เคยตอบคำขอนี้ ในบริการไม่มีเทอร์มินัลให้พิมพ์ และการเริ่มทำงานอาจค้างหรือล้มเหลวพร้อมบันทึกใน journal ที่ระบุอินพุตแทนสาเหตุ มีความลับสองอย่างเกี่ยวข้อง และแต่ละอย่างต้องมีแหล่งที่อ่านได้ของตนเองก่อนรีสตาร์ต unit ขั้นตอนด้านล่างแยกทั้งสองออกจากกัน แล้วตรวจสอบตัวตนที่เปิดแต่ละไฟล์จริง
แยกแยะคำขอทั้งสอง
วลีรหัสผ่านของคีย์ถอดรหัสคีย์ส่วนตัวท้องถิ่น ส่วนข้อมูลบัญชีรับรองเซสชันกับเซิร์ฟเวอร์ ทั้งสองมาจากคนละที่ ล้มเหลวคนละจังหวะ และให้ข้อความต่างกัน การสับสนระหว่างสองสิ่งนี้ทำให้ผู้คนไปหาการรีเซ็ตรหัสผ่านทั้งที่บัญชีไม่ได้เกี่ยวข้องเลย อ่านข้อความของคำขอก่อนเปลี่ยนตัวเลือกใด ๆ เพราะถ้อยคำเป็นเบาะแสเดียวที่เชื่อถือได้ว่าความลับใดหายไป
ใน 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 ที่มีเพียงชื่อผู้ใช้ยังทิ้งคำขอรหัสผ่านให้รออยู่ เมื่อไคลเอนต์กลายเป็นเดมอนจะขออินพุตจากเทอร์มินัลไม่ได้เลย บริการที่กำหนดค่าแบบนี้จึงไม่ขึ้น
พาธแบบสัมบูรณ์ตัดปัญหาของไดเรกทอรีทำงานออกไป แต่ไม่ได้ให้สิทธิ์เข้าถึง ต่อไปคือเจ้าของ โหมด และการผ่านไดเรกทอรี และทั้งสามอย่างตรวจกับบัญชีที่โปรเซสรันอยู่
อ่านการกำหนดค่าของ unit ก่อนโปรไฟล์
unit ไม่ใช่ไฟล์ที่คุณกำลังแก้ไข เป็นตัวกำหนดว่าอินสแตนซ์จะโหลดการกำหนดค่าใด อ่านบรรทัดคำสั่งและ drop-in ทั้งหมด แล้วตามไดเรกทอรีทำงานไปยังโปรไฟล์ที่ใช้จริง การอ้างอิงวลีรหัสผ่านที่เพิ่มในไฟล์ .ovpn อื่นไม่เปลี่ยนอะไรสำหรับอินสแตนซ์นี้
คำสั่งอ่านอย่างเดียวสามคำสั่งตอบคำถามส่วนใหญ่ได้ คำสั่งแรกพิมพ์ unit และ 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 ไฟล์ใต้ไดเรกทอรีบ้านอาจอ่านได้ในเชลล์ของคุณแต่จะมองไม่เห็นภายในบริการเมื่อไดเรกทอรีบ้านถูกซ่อน บัญชีที่ 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 ที่จำกัด ให้รันการทดสอบเดิมจากภายในมุมมองนั้น มิฉะนั้นคำตอบจะอธิบายระบบไฟล์ผิด วลีรหัสผ่านที่เก็บใต้ไดเรกทอรีบ้านที่ซ่อนอยู่เป็นตัวอย่างปกติของการทดสอบที่ผ่านนอก unit แต่ล้มเหลวภายใน
ตรวจการเริ่มครั้งแรก แล้วจึงตรวจการเชื่อมต่อใหม่
เริ่มอินสแตนซ์หนึ่งครั้งและอ่านความล้มเหลวแรกไม่ใช่ครั้งสุดท้าย ไฟล์อินพุตที่หายไป การถอดรหัสคีย์ที่ล้มเหลว และ AUTH_FAILED จากเซิร์ฟเวอร์เป็นสามเหตุการณ์ที่ต่างกันพร้อมการซ่อมสามแบบ การแก้คำเตือนเรื่องสิทธิ์ไม่ได้พิสูจน์อะไรเกี่ยวกับการปลดล็อกคีย์
บรรทัดใน journal บอกว่าคุณอยู่ในกรณีใดในสามกรณี การซ่อมขึ้นอยู่กับว่าอินพุตใดล้มเหลว:
| 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 |
จากนั้นทดสอบ วงจรชีวิตที่คุณต้องการจริง คือการเริ่มตอนบูตและการเชื่อมต่อใหม่ที่รองรับ ไม่ใช่แค่การเริ่มด้วยมือจากเชลล์ของคุณ ด้วย auth-nocache อินพุตจะถูกทิ้งหลังการใช้ครั้งแรก การเชื่อมต่อใหม่ในภายหลังจึงยังต้องมีแหล่งที่อ่านได้ กุญแจที่ปลดล็อกตอนเข้าสู่ระบบเดสก์ท็อปไม่พร้อมใช้สำหรับบริการที่เริ่มก่อนมีคนเข้าสู่ระบบ และนี่คือสาเหตุปกติที่การทดสอบด้วยมือผ่านแต่การรีบูตล้มเหลว หากการเริ่มครั้งแรกสำเร็จแต่การเชื่อมต่อใหม่ในภายหลังล้มเหลว ให้อ่าน journal สำหรับเหตุการณ์เชื่อมต่อใหม่ก่อนเปลี่ยนสิทธิ์อีกครั้ง
การเก็บวลีรหัสผ่านไว้ข้างคีย์ลดสิ่งที่การเข้ารหัสให้คุณ ดังนั้นจำกัดไฟล์นั้นและสำรองข้อมูลของมัน การลบวลีรหัสผ่านของคีย์เป็นการตัดสินใจเรื่องข้อมูลรับรองแยกต่างหาก ไม่ใช่การซ่อมอินพุตที่หายไป การติดตั้งที่พึ่งพาการอนุมัติของมนุษย์หรือ MFA แบบโต้ตอบต้องมีเอเจนต์หรือการผสานการจัดการที่รองรับ รหัสใช้ครั้งเดียวที่บันทึกถาวรไม่ใช่สิ่งทดแทนที่เท่าเทียม