เซสชันผู้ใช้ควรเป็นเจ้าของการเมานต์ SSHFS ผ่าน VPN หรือไม่

การเมานต์โฟลเดอร์ที่แชร์หลัง VPN ขึ้นมาเกี่ยวข้องกับสองตัวตนที่สับสนได้ง่าย: คอมโพเนนต์ที่ได้รับอนุญาตให้กำหนดค่าเครือข่าย และบัญชีที่ได้รับอนุญาตให้เข้าสู่ระบบเซิร์ฟเวอร์ไฟล์. พวกเขาแทบไม่เคยเป็นคนเดียวกัน ฮุก VPN ที่เป็นของ root เป็นจุดเริ่มต้นที่ไม่ดีสำหรับการเมานต์ SSHFS ของผู้ใช้เดสก์ท็อป เพราะไม่มีทั้งเอเจนต์ของผู้ใช้และความเป็นเจ้าของการเมานต์ที่ตั้งใจไว้ การกำหนดความเป็นเจ้าของให้ถูกต้องก่อนจะทำให้ทริกเกอร์ง่ายขึ้น

สองตัวตน สองสิทธิ์ที่แยกจากกัน

ไคลเอนต์ VPN ต้องมีสิทธิ์ในการเปลี่ยนเส้นทางและอินเทอร์เฟซ การเมานต์ SSHFS ต้องมีตัวตน SSH ที่เซิร์ฟเวอร์ไฟล์ยอมรับ และการเมานต์ FUSE ที่เป็นของบัญชีที่จะอ่านไฟล์ สคริปต์เดียวที่ทำงานเป็น root ตอบสนองข้อกำหนดแรกและทำลายข้อที่สองอย่างเงียบ ๆ

การเมานต์เป็น root ทำให้ไฟล์อยู่นอกเซสชันเดสก์ท็อปและอาจเข้าถึงเอเจนต์ที่เก็บคีย์ของผู้ใช้ไม่ได้ การเมานต์มีอยู่ ผู้ใช้เขียนผ่านไม่ได้ และความล้มเหลวดูเหมือนปัญหาสิทธิ์ฝั่งเซิร์ฟเวอร์ การวินิจฉัยผิดนั้นทำให้เสียเวลาหนึ่งบ่ายและตั๋วถึงทีมจัดเก็บข้อมูล

ตัดสินใจว่าบัญชีใดเป็นเจ้าของการเมานต์ก่อนเขียนระบบอัตโนมัติใด ๆ เพราะตัวเลือกนั้นกำหนดว่าทริกเกอร์อาศัยอยู่ที่ใดและเข้าถึงข้อมูลรับรองใดได้

ก่อนอื่นให้สร้างการเมานต์ที่เป็นของผู้ใช้ด้วยมือ

เริ่มจากผู้ใช้ที่ลงชื่อเข้าใช้ซึ่งมีจุดเมานต์ว่าง บัญชี SSH ที่ได้รับอนุญาต และเส้นทางที่ใช้งานได้ไปยังเซิร์ฟเวอร์ผ่านอุโมงค์ การเมานต์ด้วยมือเป็นตัวกำหนดพื้นฐานที่ระบบอัตโนมัติใด ๆ ต้องทำซ้ำ

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

ชื่อเป็นตัวอย่าง ดังนั้นให้แทนที่โฮสต์และเส้นทางส่งออกที่เซิร์ฟเวอร์ของคุณให้บริการจริง ตรวจสอบคีย์โฮสต์ผ่านกระบวนการที่ได้รับอนุมัติในการเชื่อมต่อครั้งแรกนั้น โปรดทราบว่ารหัสผ่านบัญชี VPN ไม่ใช่ข้อมูลรับรองของบัญชีจัดเก็บข้อมูลโดยอัตโนมัติ และนั่นเป็นสาเหตุทั่วไปของความพยายามที่ล้มเหลว

เรียกใช้ในฐานะผู้ใช้ปกติด้วยจุดเมานต์ที่เป็นของผู้ใช้คนนั้น โดยค่าเริ่มต้นมีเพียงบัญชีที่เมานต์เท่านั้นที่เข้าถึงไฟล์ และ allow_other ขยายขอบเขตนั้นไปยังผู้ใช้ภายในทุกคน นั่นคือการขยายการเข้าถึงโดยเจตนา ไม่ใช่วิธีเลี่ยงสำหรับระบบอัตโนมัติ

ให้ทริกเกอร์ทำงานในบริบทเซสชันเดียวกัน

ให้การรวมเหตุการณ์ VPN ที่รองรับขอให้เรียกใช้การกระทำของเซสชันผู้ใช้ แทนที่จะสันนิษฐานว่าคอลแบ็กที่มีสิทธิ์พิเศษสามารถยืมข้อมูลรับรองเดสก์ท็อปได้ จำกัดทริกเกอร์ให้เหลือตัวระบุการเชื่อมต่อที่ตั้งใจไว้ ไม่ใช่อินเทอร์เฟซใดที่บังเอิญชื่อ tun0 กฎของตัวส่งที่ตรงกับสิ่งผิดจะทำงานทุกครั้งที่เครือข่ายเปลี่ยน รวมถึงสิ่งที่ไม่มีส่วนเกี่ยวข้องกับการเมานต์นี้

การกระทำควรยืนยันชื่อโฮสต์ที่คาดไว้ สังเกตการเมานต์ที่มีอยู่ และพยายามหนึ่งครั้งอย่างจำกัด ลูปโพลที่เริ่มโปรเซส SSHFS ใหม่ทุกไม่กี่วินาที หรือลองขอข้อมูลรับรองซ้ำขณะเซิร์ฟเวอร์ล่ม จะเปลี่ยนการหยุดชะงักสั้น ๆ ให้เป็นกองโปรเซสที่ค้างอยู่ จำกัดความพยายามด้วยเวลาหมดอายุและการลองใหม่เพียงครั้งเดียว

nmcli -g UUID connection show --active
systemctl --user list-units 'sshfs*'
pgrep -a sshfs

คำสั่งแรกให้ตัวระบุการเชื่อมต่อที่ตัวส่งควรจับคู่ อีกสองคำสั่งแสดงว่ามีความพยายามกำลังทำงานอยู่แล้วหรือไม่ และนั่นคือการตรวจสอบที่ป้องกันข้อมูลซ้ำ

บริการที่ไม่มีผู้ดูแลต้องมีข้อมูลรับรองที่ได้รับอนุมัติของตนเองและการตรวจสอบโฮสต์ของตนเองในบริบทการทำงานของตนเอง ไม่สามารถสันนิษฐานได้ว่าเอเจนต์กราฟิกถูกปลดล็อก และไม่ควรพยายามปลดล็อก

วางแผนการตัดการเชื่อมต่อก่อนบังคับทำความสะอาด

สำหรับการตัดการเชื่อมต่อตามแผน ให้ทำงานกับไฟล์ให้เสร็จและถอนเมานต์จากเวิร์กโฟลว์ของผู้ใช้ที่เมานต์เอง กำหนดเป้าหมายที่จุดเมานต์ไม่ใช่โปรเซส และยืนยันผลลัพธ์ก่อนรายงานความสำเร็จ

fusermount3 -u "$HOME/mnt/team"
mountpoint "$HOME/mnt/team"

ถอนเมานต์เฉพาะการเมานต์ที่เวิร์กโฟลว์นี้สร้างขึ้นเท่านั้น หากกำลังถูกใช้งาน นั่นคือการตัดสินใจของแอปพลิเคชัน: การแยกแบบบังคับที่มีอยู่เพื่อให้ฮุกคืนความสำเร็จกลับซ่อนการสูญเสียข้อมูลแทนที่จะป้องกัน

การสูญเสียที่ไม่คาดคิดมีพฤติกรรมต่างออกไป SSHFS ระบุว่าการขัดจังหวะเครือข่ายสามารถบล็อกการดำเนินการของระบบไฟล์ได้ และตัวเลือก reconnect จะคืนค่าการรับส่งโดยไม่คืนค่าแฮนเดิล ไฟล์ที่เปิดก่อนการเชื่อมต่อใหม่อาจล้มเหลวในการเขียนครั้งถัดไป และการเขียนที่ถูกขัดจังหวะจะไม่ถูกเก็บไว้ ความแตกต่างนี้สำคัญที่สุดสำหรับโปรแกรมแก้ไขที่เปิดไฟล์เดียวค้างไว้หลายชั่วโมง วางแผนขั้นตอนเปิดใหม่แทนการสันนิษฐานว่ากู้คืนได้

ทดสอบพฤติกรรมด้วยไฟล์ที่ใช้แล้วทิ้งก่อนพึ่งพา ไดเรกทอรีที่ปรากฏขึ้นอีกครั้งหลังอุโมงค์กลับมาไม่ได้พิสูจน์ว่าแฮนเดิลก่อนหน้าหรืองานที่ยังไม่บันทึกอยู่รอด