Mountain Duck SFTP: การเข้าสู่ระบบครั้งที่สองหลัง VPN
เกตเวย์และเซิร์ฟเวอร์ไฟล์ตรวจสอบคนละสิ่ง ใช้ชื่อโฮสต์ของผู้ดูแลระบบ SFTP ตอบพรอมต์ของระบบ และเก็บการตรวจสอบคีย์โฮสต์ไว้
VPN เชื่อมต่อได้ แถบเมนูแสดงอุโมงค์ แต่ Mountain Duck ยังขอให้เข้าสู่ระบบ จากนั้นขอรหัส ไม่มีอะไรเสีย: มีสองระบบที่ต่างกันกำลังตรวจสอบตัวคุณ และระบบที่สองไม่เคยรู้จักระบบแรกเลย MFA ของ VPN พิสูจน์บางอย่างต่อเกตเวย์ เซิร์ฟเวอร์ SFTP ขอหลักฐานของตัวเอง เทียบกับบัญชีของตัวเอง
สองพรอมต์ สองระบบ
เกตเวย์และเซิร์ฟเวอร์ไฟล์เป็นโดเมนนโยบายที่แยกจากกัน อาจใช้ไดเรกทอรีร่วมกัน หรืออาจไม่มีอะไรเหมือนกันเลยนอกจากคนที่ใช้งาน การส่งรหัสใช้ครั้งเดียวที่ VPN ไม่ได้สร้างเซสชันบนโฮสต์ SFTP และโฮสต์ SFTP ก็ไม่รู้ว่าคุณได้ใช้อุโมงค์หรือไม่ แต่ละระบบคิดว่าตนเป็นผู้ถามเพียงรายเดียว
| Layer | What it authenticates | Where the account lives |
|---|---|---|
| VPN | The tunnel endpoint | Gateway or identity provider |
| SFTP | The file session | SSH server or its directory |
| Folder access | Read and write within the share | Filesystem permissions |
ให้ถือว่าทั้งสามเป็นบรรทัดแยกกันในบันทึกของคุณ เมื่อตัวใดตัวหนึ่งล้มเหลว บรรทัดนั้นบอกว่าต้องเปิดคอนโซลไหน และนั่นคือส่วนใหญ่ของงาน
ใช้ที่อยู่ของผู้ดูแลระบบ SFTP
บุ๊กมาร์กต้องใช้ชื่อโฮสต์และพอร์ตที่บริการไฟล์รับฟังจริง ซึ่งไม่จำเป็นต้องเป็นที่อยู่ของเซิร์ฟเวอร์ VPN ถามผู้ดูแลที่รับผิดชอบบริการ SFTP และใช้ชื่อโฮสต์เดียวกับที่ไคลเอนต์อื่นใช้
เก็บการตรวจสอบตัวตนของเซิร์ฟเวอร์ไว้ให้ครบ Mountain Duck และ Cyberduck แสดงคีย์โฮสต์เมื่อเชื่อมต่อครั้งแรก และการนำไปเทียบกับค่าที่ผู้ดูแลให้มาผ่านช่องทางอื่นคือขั้นตอนที่กันไม่ให้เซิร์ฟเวอร์ผิดได้รับข้อมูลรับรองของคุณ การปิดการตรวจสอบนั้นเพื่อให้บุ๊กมาร์กเชื่อมต่อได้เป็นการตัดสินใจถาวรที่ปลอมเป็นความสะดวก และยังลบหลักฐานเดียวที่คุณจะมีในภายหลังว่าไฟล์ไปถึงที่ที่ตั้งใจ
ตอบการท้าทายที่เซิร์ฟเวอร์ส่งมา
เอกสาร SFTP ของโครงการอธิบายการรองรับการท้าทาย-ตอบสนองสำหรับรหัสใช้ครั้งเดียว: พรอมต์เข้าสู่ระบบครั้งแรก แล้วตามด้วยพรอมต์ที่สองสำหรับรหัส ตามที่เซิร์ฟเวอร์ร้องขอ ขั้นตอนนี้เป็นของการกำหนดค่าเซิร์ฟเวอร์ และไคลเอนต์ไม่สามารถเพิ่มการบังคับใช้สองปัจจัยฝั่งเซิร์ฟเวอร์ได้ด้วยการเก็บค่าอื่นในช่องรหัสผ่าน
ดังนั้นบุ๊กมาร์กควรเก็บข้อมูลรับรองบัญชีปกติ และรหัสควรถูกพิมพ์เมื่อพรอมต์ปรากฏ การบันทึกรหัสที่เปลี่ยนแปลงได้เป็นรหัสผ่านถาวรทำให้เกิดบุ๊กมาร์กที่ใช้ได้ครั้งเดียว แล้วล้มเหลวในลักษณะที่ดูเหมือนรหัสผ่านผิด การใส่รหัสลงในช่องข้อมูลรับรองของ VPN ล้มเหลวต่างออกไป: เกตเวย์ปฏิเสธ และอุโมงค์ไม่ขึ้นเลย พรอมต์สองครั้ง สองตำแหน่ง และการสลับกันทำให้ทั้งคู่เสีย
การเมานต์อัตโนมัติกดปุ่มไม่ได้
หากบุ๊กมาร์กเชื่อมต่อใหม่ในเบื้องหลัง การท้าทายแบบโต้ตอบไม่มีใครตอบ การเมานต์ลองอีกครั้ง เซิร์ฟเวอร์ถามอีกครั้ง และบันทึกเต็มไปด้วยความพยายามที่ไม่สามารถสำเร็จได้ นั่นคือผลลัพธ์ที่ตรงไปตรงมาของนโยบายที่ต้องการคน
วางแผนการโต้ตอบ: เชื่อมต่ออุโมงค์และบุ๊กมาร์กขณะที่คุณอยู่ที่นั่น แล้วถือว่าการเชื่อมต่ออัตโนมัติในภายหลังเป็นความพยายามที่ดีที่สุด หากกระบวนการทำงานต้องการการเข้าถึงแบบไม่มีคนเฝ้าจริง ๆ เจ้าของเซิร์ฟเวอร์ต้องอนุมัติการจัดรูปแบบการยืนยันตัวตนอื่น ซึ่งเป็นการเปลี่ยนนโยบายไม่ใช่การตั้งค่าบุ๊กมาร์ก
การเมานต์ไม่ใช่สิทธิ์
ไดรฟ์ที่เมานต์แล้วพิสูจน์ว่าเซสชันได้รับการยืนยันตัวตนแล้ว ไม่ได้พิสูจน์ว่าบัญชีเขียนได้ทุกที่บนเซิร์ฟเวอร์นั้น ตรวจสอบโฟลเดอร์ที่ต้องการ ลองทำการดำเนินการที่คุณต้องการจริง และยืนยันผลจากฝั่งเซิร์ฟเวอร์เมื่อคำตอบมีความสำคัญ แถบด้านข้างของ Finder แสดงไดรฟ์ แต่ไม่ได้บอกอะไรเกี่ยวกับสิทธิ์ที่อยู่เบื้องหลัง
สำหรับโปรโตคอลอื่น ให้ใช้วิธีการยืนยันตัวตนที่เอกสารของผู้ให้บริการนั้นระบุ แทนที่จะคัดลอกลำดับนี้ การลงชื่อเข้าใช้คลาวด์และการท้าทาย SSH อาจดูเหมือนกันในแถบด้านข้าง แต่ทำงานต่างกันโดยสิ้นเชิงภายใน